Following Canvas 2D dev spec: added without discussion.

TL;DR: The Canvas development spec maintained at dev.w3.org has 
undergone some massive changes.

As for my idea of moving forward:
partial interface CanvasRenderingContext2D {
   void addPathData(DOMString d);
}

addPathData is in Ian's development specification and the concept has 
been vetted in several places. It's been used by many Canvas authors. I 
suggest adding it to the Canvas 2D context, not the new "Path" object.
http://dev.w3.org/html5/2dcontext/Overview.html#dom-path-addpathdata

Beyond that, I recommend ignoring the development draft of Canvas held 
on "dev.w3.org" given its instability and its proprietary development 
procedures.

-Charles

......

By looking here, we can see that the editor has departed widely from a 
stable draft:
http://dev.w3.org/html5/2dcontext/

This is in contrast to the mildly out of date working draft from May 2011:
http://www.w3.org/TR/2dcontext/

These changes have been made without consultation with this group nor 
public consideration of existing proposals. The changes were made 
without visible commentary by browser vendors. Though they touch on some 
desired features, they do so in a way that has not been tested nor 
discussed by implementers nor developers. They do not reflect any 
existing implementations.

The Canvas 2D specification has been altered unilaterally, and this 
change will further confuse implementers as well as developers as to 
what it is they ought to be working on. The changes were mentioned in 
the WHATWG Wiki on Canvas2D.

On the positive side, the spec editor does see value in supporting the 
SVG path strings. The editor also seems to see some value in supporting 
regions, calling them "addHitTesting" though not yet including them in 
the development draft.

I voiced my concerns about the WHATWG Canvas extensions shortly after 
they were published. It's unnecessary to have a new Path object 
containing the full set of drawing commands. Using a createPath method 
on the Canvas 2D context would work well and be in line with the rest of 
the APIs. Note that the WHATWG did not invent Canvas, nor does the 
editor actively use the API.

The attempt to rig paths as paint servers for fill and stroke may create 
an unneeded burden on implementers at a time when achieving 
accessibility is far more important. These methods are not particularly 
flexible nor proven. They've not been put up for discussion nor testing. 
The "Path" object is something that could be developed separately from 
the Canvas 2D API, and perhaps that's what the intention is.

Path objects as they are serialized and held by underlying drawing APIs 
can be used effectively through different methods than those outlined in 
the spec editors changes.

Unfortunately, this process seems wildly out of the hands of the W3C 
chairs, given that Canvas 2D is edited by the HTML5 spec editor, and he 
is loathe to engage in cooperative group process. We're all along for 
the ride.

-Charles

PS: The following methods require minimal changes to existing specs and 
can be implemented effectively and efficiently atop existing drawing 
APIs without further cache management of path objects needed for 
optimization.

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

We have already asked for addEventTarget(element) as a means of binding 
paths to elements for A11y, specifically, Apple's VoiceOver and 
AISquared's ZoomText. These ought to be the current focus of 
implementers concerned with technical aspects of implementation and 
efficient use of time and resources.

The editor's creation of a "Path" object may be appropriate under a 
different context, but not under the guise of the Canvas 2D API. It may 
be very appropriate for the SVG2 specification.

-Charles

Received on Wednesday, 14 March 2012 01:07:33 UTC