Re: hixie has proposals for regions and path primitives additions to the 2d context spec

The main take-away here is that the HTML5 editor has put forward a rough 
proposal of region-based hit bound to DOM elements. That's great. That's 
some progress three years in the making.

We've yet to hear back from Apple and Mozilla about this methodology. 
Apple responded last year that they did not believe Canvas should be 
used with "retained mode" semantics. They've not been back. When/if 
Apple and Mozilla are on-board, we can claim a broad consensus that 
region-based hit testing should be added to the API.

As for Hixie's current proposal: addHitTesting; I'd prefer it was called 
"addEventTarget".

Hixie proposes two new features: virtual elements, and binding 
strokeText and fillText by default to the a11y API.

I am tempted by the virtual element proposal. As of yet, the SVG WG has 
not taken up David Dailey's replicate semantics. Those semantics cover 
the main cases I've relied on Canvas for: free-form drawing and stylized 
glyphs. They've been rejected from SVG2, so far. I'm still arguing that 
they're necessary for a decent implementation of InkML rendering in SVG.

SVG Replicate:
http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/replicate.htm

Hixie's virtual elements are light elements that are not present in the 
DOM, but do contain: "role", "label" and an identifier. I'm tempted by 
them, but I'm concerned that departing from the DOM will mean shrugging 
our responsibility to keep things programatically accessible.

Building on the virtual elements feature, Hixie suggests that all 
existing instances of strokeText and fillText should create an 
accessible object, its label being the content of the text passed 
through the methods.

I am again concerned: while this would certainly have benefits with some 
existing Canvas pages, it may result in a whole lot of duplicates in the 
accessibility tree, and may not work with many situations currently used 
today with animation and glyph painting.

It may require additional clearRect calls instead of simple fillRect 
calls, and could otherwise add complexity and confusion to the API. It 
simply doesn't fit with current semantics.

I have to come out against virtual elements at this time.

I am glad to see that binding the current path to a sub-tree element (in 
the DOM) was included in Hixie's proposal. Frank Olivier, Hixie, myself 
and Richard have suggested this feature.

At present, Hixie's proposal is a bit far reaching, and re-engages some 
of the earlier ideas that floated around last year, such as using 
clearRect to clear the canvas. For reasons we've previously discussed, I 
don't think these kinds of features are appropriate for the Canvas API.

-Charles

On 2/27/2012 10:01 PM, Steve Faulkner wrote:
> hi all,
>
> hixie has proposals for regions and path primitives additions to the 
> 2d context spec
>
> http://wiki.whatwg.org/wiki/Canvas#Proposals
>
>
> -- 
> with regards
>
> Steve Faulkner
> Technical Director - TPG
>
> www.paciellogroup.com <http://www.paciellogroup.com> | 
> www.HTML5accessibility.com <http://www.HTML5accessibility.com> | 
> www.twitter.com/stevefaulkner <http://www.twitter.com/stevefaulkner>
> HTML5: Techniques for providing useful text alternatives - 
> dev.w3.org/html5/alt-techniques/ <http://dev.w3.org/html5/alt-techniques/>
> Web Accessibility Toolbar - 
> www.paciellogroup.com/resources/wat-ie-about.html 
> <http://www.paciellogroup.com/resources/wat-ie-about.html>
>