W3C home > Mailing lists > Public > public-html@w3.org > March 2012

Re: Revert request r7023

From: Charles Pritchard <chuck@jumis.com>
Date: Tue, 13 Mar 2012 19:23:48 -0700
Message-ID: <4F600134.2050007@jumis.com>
To: Maciej Stachowiak <mjs@apple.com>
CC: "Tab Atkins Jr." <jackalmage@gmail.com>, HTML WG <public-html@w3.org>
On 3/13/12 7:07 PM, Maciej Stachowiak wrote:
> On Mar 13, 2012, at 6:54 PM, Charles Pritchard wrote:
>> On 3/13/12 6:28 PM, Tab Atkins Jr. wrote:
>>> On Tue, Mar 13, 2012 at 6:16 PM, Charles Pritchard<chuck@jumis.com>   wrote:
>>>> It's my contention that the editor's "Path" object, as it is authored, is
>>>> not appropriate for Canvas 2D but may be appropriate for SVG2. An
>>>> alternative "CanvasPath" object, much simpler and effective, was proposed
>>>> last year.
>>> The Path object being added to the spec right now is a result of
>>> addressing many bugs asking for added canvas functionality since the
>>> last time Hixie touched that part of the spec.  Presumably if the
>>> simpler CanvasPath addressed the use-cases implied by the bugs he's
>>> addressing, he would have used it.  Simpler's usually better, after
>>> all.
>>> It makes little sense for SVG to define a<canvas>   API.
>> Presumably, the author of the spec would have more experience implementing and using it. But, he doesn't. So he's doing the best he can. Presumably the editor would solicit authoring materials and/or solutions from experts and act as an editor. But, he doesn't. So he's doing the best he can.
>> There's nothing in the Path object that's unique or restricted to the Canvas 2D API. It makes a lot of sense for SVG to have a short and easy path building API. And that's likely the intention behind the "Path" API. Note the lack of prefix. Items from Canvas usually have "Canvas" prefixed to their names. Take a look at that Path API, it'd fit just fine in SVG.
> To be clear, is your objection to the fact that the name is "Path" instead of "CanvasPath", or other API details you disagree with? Can you cite a reference for the CanvasPath proposal? I couldn't find it through web searching.

My objections are:
1. "Path" instead of "CanvasPath"
2. "Path implements CanvasTransformation;
Path implements CanvasLineStyles;
Path implements CanvasPathMethods;
Path implements CanvasText;"
instead of "// opaque object".
3. "addFill, addStroke, addFillText and addStrokeText variants" instead 
of just not having them.
4. Adding "Path" variant methods on "clip", "fill", "stroke", and 
"drawFocusRing" instead of having one addPath or setFromPath method.

There was an early discussion in 2011, it's been repeated since:
The names are not particularly important, but this is Canvas oriented.

In short:
partial interface CanvasRenderingContext2D {
    void addPathData(DOMString d);
    void addPathData(CanvasPath path);
    CanvasPath createPath();
interface CanvasPath {
   // opaque object


My final objection is in the way this was approached: without consensus 
or due priority for the working group and/or participants of the Canvas 
API mailing list and the Last Call poll.

The editor has stated that "even discussing" of some accessibility APIs 
may be harmful to the web, that he is controlling the Canvas 2d spec as 
a means of slowing implementers, that simple, contained solutions are 
"piecemeal" and that we shouldn't be stating solutions anyway, just the 
problems, so he can figure them out.

That is not a positive working environment. While I'm all for benevolent 
dictatorship, it needs to come with some measure of expert consultation. 
Otherwise we get the benevolent leader of North Korea and people are 
left out in the cold.

"Effectively, even discussing an API for carets and selections
could be argued to be harmful to the Web's accessibility"

"the moment I add anything to canvas, everyone implements it, dropping 
whatever else they were working on, and so if I keep adding  canvas 
features nothing else gets done"

"I think it would be a mistake to address this [proposal] in a piecemeal 

To an off-list group, regarding the previous proposal:
"Simply stating problems like this, *without saying how you want it 
fixed*, is the best way to make progress here."

Received on Wednesday, 14 March 2012 02:24:13 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:50 UTC