[whatwg] Rename the 7-arg arcTo() to ellipseTo()?
Tab Atkins Jr.
jackalmage at gmail.com
Mon Sep 24 15:18:08 PDT 2012
On Mon, Sep 24, 2012 at 1:14 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 24 Sep 2012, Tab Atkins Jr. wrote:
>> > Omitting two numbers, one of which is zero, is easily no more a win
>> > than the cost of having two different nearly-identical commands. Just
>> > consider C/c and S/s; is it really worth it?
>> Yes, it is. ^_^ The authoring convenience of not having to repeat
>> things, or not having to read past useless things, is fairly
> Do we have any data on this? If this really is a concern, it may suggest
> that maybe the whole path syntax should be rethought. As it stands it
> already has quite a lot of repetition. For example, look at the amount of
> repetition in the examples for A/a in the SVG spec.
Yes, the A/a commands (ArcBetween) are elliptical-only, which is
problematic. As part of our revamping of paths, particular the arc
syntaxes, I'll be proposing a circular ArcBetween as well. That
eliminates the repetition.
>> > What's wrong with A/a? It seems to be equivalent to arcTo(). Is it
>> > arc() that you want to add? I'm very confused.
>> Oh, no, they're *completely* different. arcTo() is *great*, because
>> it's convenient and solves a useful problem (rounding a corner) without
>> you having to do much math. For A, you have to determine the start/end
>> points on the circle yourself, usually involving trig. The only
>> similarity between the two commands is that they both draw an arc as
>> part of their operation.
> I don't really follow.
> The main use case for arcTo() is rounded corners. With A/a, these are
> trivial. Consider a 300x150 rectangle with 10px radius corners, top left
> corner at 0,0. There's no trig necessary, you just give the points on each
> side, with the radius as offset:
> d="M10,0 H290 A10,10 0 0 1 300,10
> V140 A10,10 0 0 1 290,150
> H10 A10,10 0 0 1 0,140
> V10 A10,10 0 0 1 10,0
> (The Z isn't really necessary.)
> If anything, I'd say this is better than what you have to do with
> arcTo(), since with that one you have to give both the corner coordinate
> and the destination coordinate, rather than just the latter.
> Could you elaborate on what exactly it is that is being done here? If
> there were some examples showing the problems that would really help.
You are looking at the simplest possible use-case for A/a, nearly the
only case that can be done without trig, where you're starting and
stopping the arc at a quarter-turn. Try virtually anything more
complex, like rotating the square 45deg. Using arcTo it's still
trivial - you just need to know enough trig to figure out that the
corners are now at (0, 1.414), etc., and the command takes care of the
rest for you. With A/a, you need to do a bit more to translate the
points of the diamond into the start/end of the arc.
Don't even get me started on trying to do a 5-pointed star with rounded corners.
In general, if you can do a sharp corner, you can do a rounded corner
with arcTo. You need no additional information. arcBetween almost
always needs significantly more information.
More information about the whatwg