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

[Ian Hickson]

On Mon, 24 Sep 2012, Dirk Schulze wrote:
> 
> Making the path syntax more complex than it needs to be seems not to be 
> an option for me.

It's definitely an option, assuming this is not a trivial statement, 
because it's no the only axis along which the syntax can be optimised, and 
it is not the axis that has been used previously. Specifically, the path 
syntax has clearly been optimised for terseness and power, at the expense 
of simplicity.

Nothing can quite mess up an API or language like changing optimisation 
function (changing design philosophy) half-way through its life. You end 
up with languages that feel like they have multiple personality disorder, 
and it ends up being much harder to learn the language than if it was 
consistent with itself but overall more complicated than possible.

That is, a language that has complexity 10 throughout is easier to learn 
and use than a language that is half complexity 10 and half complexity 1. 
This is a lesson we have learnt many times on the Web, not least of which 
with HTML, which has lurched in many directions over its lifetime, 
leaving authors highly frustrated and confused.


> To be honest it seems very confusing to me that Canvas has arc() and 
> ellipse() but no ellipseTo() as pendant to ellipse().

ellipse() exists only because arc() already had optional arguments and the 
resulting API had arc() been extended to support ellipse()'s use case 
would have been to have the radii arguments split or to have optional 
arguments in the middle, which is IMHO even worse than adding another 
method. It's an unfortunate situation, certainly.


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.)


> We prefer using the names "arc" and "ellipse" to denote circular and 
> elliptical variants of the commands.

I think this will make the path language really ugly, assuming you're 
talking about the commands and not the names (as in, the strings in d="" 
will now be long instead of one-letter commands), and I question whether 
this makes sense, but that's a discussion for the www-svg list.


> 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.


> 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.


> 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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'