[whatwg] Rename the 7-arg arcTo() to ellipseTo()?
Tab Atkins Jr.
jackalmage at gmail.com
Mon Sep 24 16:57:14 PDT 2012
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
> 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
> 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.
More information about the whatwg