- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 24 Sep 2012 23:32:18 +0000 (UTC)
- To: Dirk Schulze <dschulze@adobe.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: WHATWG List <whatwg@whatwg.org>
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. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 24 September 2012 23:35:06 UTC