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

[Dirk Schulze]

On Sep 24, 2012, at 4:32 PM, Ian Hickson <ian at hixie.ch> wrote:

> 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.
And this simplicity is asked from developers over the power of the existing segments. It is already strange that not even authoring tools use a/A, neither Illustrator nor Inkscape, the most famous SVG creation tools.

> 
> 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.
Sometimes this is the price of backwards compatibility.

> 
> 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.
Well, we just add new segments and don't mess up the existing syntax. Authors have the freedom to choose between the path syntax they want.


> 
> 
>> 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.
I believe you that this wash't your intention initially, but the inconsistency is the naming now. Canvas has arc and ellipse on the one side and just arcTo on the other side.

> 
> 
> 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.)
Yes, there have been optional arguments before. The question is just related to arcTo() and ellipseTo() they don't need to differ so much from the idea of arc() and ellipse().

> 
> 
>> 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.
This is a separate discussion and you can definitely mail to www-svg raising this concern. At some point SVG runs out of meaningful letters :)

> 
> 
>> 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.
Not if we have the feedback of authors that the current syntax is to complex for a lot of cases. It doesn't make sense to act against wishes of web authors.

> 
> 
>> 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.
I don't see the changes on SVG as a requirement for Canvas to change the API. I am just in favor for a harmonization. Canvas and SVG don't need to be two fully separate drawing languages. There is a lot of interest from web authors to use both.

Greetings,
Dirk

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