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

[Tab Atkins Jr.]

On Thu, Sep 20, 2012 at 4:58 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 17 Sep 2012, Tab Atkins Jr. wrote:
>> Heya, we at the SVGWG just resolved today to add equivalents for the
>> CanvasPathMethods interface arc/ellipse/arcTo commands to the <path>
>> element's syntax.
>>
>> Ideally, we'd be able to use the same names as Path, for minimal
>> confusion - "<path d='M0 0 arc 30 30 10 0 90 0'>" producing a line from
>> (0,0) to (40,30), then a quarter-arc to (30,40).  However, this is
>> problematic for arcTo(), as it has both a 5-arg (for circular arcs) and
>> a 7-arg (for elliptical arcs) version.  For one, this is somewhat
>> inconsistent with the pattern established by the existing arc() and
>> ellipse() functions.  For two, and worse for SVG, SVG typically allows
>> you to omit the name of the path command if the immediately previous
>> command was the same name.  To do this, the command needs to have a
>> constant number of arguments, so you can just split on every Nth arg.
>>
>> So, we're going to have to name the 7-arg version something different.
>> The obvious answer is "ellipseTo".  Could we change the
>> CanvasPathMethods interface to do the same?  To the best of my
>> knowledge, no implementations exist yet for the 7-arg version, so
>> there's no backwards-compat issues.
>
> The last argument to the arc() method was optional before we added the
> ellisoid features -- it's actually the ellipse() function that doesn't
> follow the pattern, I just couldn't work out a good way to add the new
> radius to the existing arc() method (because of its existing optional
> argument), which is why I gave up and added a new method.
>
> I recommend just always requiring all the arguments.

We do require all arguments.  As I explained in the OP, the SVG <path>
syntax can't have optional arguments, since it allows repeating the
command's args without repeating the command name.

So, can we rename the 7-arg arcTo to ellipseTo?  That seems to support
your "always [require] all the arguments" recommendation. ^_^

> In general, though, I wouldn't recommend trying to do this at all. The SVG
> path syntax is its own thing, and it already supports arcs and so forth.
> Adding a whole new redundant set of commands that work slightly
> differently is just bloat asking for interop issues, IMHO. The design of
> the path syntax makes sense, it's terse. Embrace its strengths, don't
> second-guess its design.

The existing SVG "A" command is one of the largest source of
complaints from hand-authors.  While it's *occasionally* useful as
stated, it often requires you to do trig to get the effect you want.
The Canvas arc commands, with their use of an angle to sweep across,
are exactly what authors want a lot of the time, and commonly ask for.
 That's why we're adding these additional forms of arcing.

~TJ