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

[Tab Atkins Jr.]

On Mon, Sep 24, 2012 at 3:50 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 24 Sep 2012, Tab Atkins Jr. wrote:
>> 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.
>
> Fair enough.
>
> Anyway, my original point stands: I don't see why this would have any
> impact on the canvas API. The API to be consistent with is the existing
> path API, not the canvas one. If you did want to introduce optional
> arguments to the path API, though, that would be relatively trivial; just
> introduce a punctuation mark that means "end of arguments", e.g. "/".
>
>    B 10,10 20,20 5 / 30,30 40,40 10
>
> ...instead of:
>
>    B 10,10 20,20 5 5 0 30,30 40,40 10 5 0
>
> ...(where B is a command that takes the same arguments as arcTo().)

Returning to the original subject, we don't *want* optional arguments
here.  We prefer using the names "arc" and "ellipse" to denote
circular and elliptical variants of the commands.  Right now, the
canvas path API is inconsistent with itself, using arc/ellipse in one
place, and using arc with optional arguments in another.  We would
prefer to align the syntaxes of canvas path and SVG path as much as
possible, to help authors translate knowledge between the two.  As
such, we're requesting that the canvas path API change to be
consistent with itself, in the direction that we prefer.

~TJ