Re: [whatwg] Rename the 7-arg arcTo() to ellipseTo()?

On Mon, Sep 24, 2012 at 1:14 PM, Ian Hickson <ian@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
>> significant.
>
> 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
>       Z"
>
> (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.

~TJ

Received on Monday, 24 September 2012 22:23:09 UTC