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

[Tab Atkins Jr.]

On Mon, Sep 24, 2012 at 4:32 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 24 Sep 2012, Tab Atkins Jr. wrote:
>> Returning to the original subject, we don't *want* optional arguments
>> here.
>
> Well, the canvas API has optional arguments, so there's no way to be
> consistent with canvas with this constraint. (This is the case even before
> ellipses are considered.)

This is a very minor inconsistency, and one that we feel is acceptable.

>> Right now, the canvas path API is inconsistent with itself, using
>> arc/ellipse in one place, and using arc with optional arguments in
>> another.
>
> Specifically, it's using arc and arcTo with optional arguments, and
> ellipse separately, because arc couldn't be extended sanely the way arcTo
> could be.

Yes.  What's your point?  That is inconsistent.

>> 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.
>
> I think it would be far more useful for SVG to be consistent with itself,
> have no similarity with canvas, and present a sane language, than to have
> SVG inconsistent with both itself and canvas, and present a fractured
> language that is hard to learn.

Please stay on topic here.  SVG won't be "inconsistent with both
itself and canvas".  It will introduce long-form names for *all* of
its commands (the single-letter commands were already showing their
limits - I mean really, T?).

>> As such, we're requesting that the canvas path API change to be
>> consistent with itself, in the direction that we prefer.
>
> I believe the canvas API is adequately consistent with itself given the
> constraints facing this API's evolution, and so have not changed it.

That's unfortunate.  SVG is unable to match canvas, then, and must
unnecessarily confuse authors by having *three* of its new arcing
commands match canvas, but not the fourth.

~TJ