- From: Charles Pritchard <chuck@jumis.com>
- Date: Tue, 13 Mar 2012 18:07:08 -0700
- To: Canvas <public-canvas-api@w3.org>
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