W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2012

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

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 20 Sep 2012 23:58:53 +0000 (UTC)
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Message-ID: <Pine.LNX.4.64.1209202350450.27765@ps20323.dreamhostps.com>
Cc: WHATWG List <whatwg@whatwg.org>
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.

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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 20 September 2012 23:59:19 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:45 UTC