On 12/20/11 2:22 AM, Jonas Sicking wrote:
> On Mon, Dec 19, 2011 at 1:19 PM, Richard Schwerdtfeger
> <schwer@us.ibm.com <mailto:schwer@us.ibm.com>> wrote:
>
> Do you support Frank moving forward with the setElementPath/hit
> test proposal for the working group to review and are you still
> supportive of having such an API for canvas?
>
>
> I honestly have lost track of what the latest proposal is at this
> point. The main goal I have is to create an API which is simple enough
> to use for people to want to do their own canvas hit-testing using the
> API we provide. That is how we can get the most number of people to
> use these APIs, and thus create the most accessible web.
>
Frank's comment for setElementPath(element):
http://www.w3.org/wiki/Canvas_hit_testing
Here is the bug report (scroll to bottom):
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13176
I spoke with several Canvas programmers, they felt that if hit testing
were available in the API, they'd use it. They wanted it to be
available. They're not particularly fascinated by the idea of using the
DOM. I'm fascinated by the idea of using DOM+ARIA with Canvas as part of
UI development. I think they'll be easily swayed once they start using it.
We had a many months discussion about use cases. Intuitively, I think
most of us did not want to see additional complexity added to the Canvas
specification. Hit testing is [was] a commonly requested feature by
Canvas developers; many vendors saw it as an attempt to "bolt on"
retained-mode semantics.
It's the DOM that does all of the retained-mode work.This is simply a
means of "super charging" image maps. As I understand it, the only
reason developers are getting this gift is because there's no practical
solution to the accessibility issue, other than granting developers the
ability to associate a region with a DOM node.
There are solutions other than this new method, but those solutions are
not well integrated with Canvas and we can look at the past few years of
Canvas development to see that a poorly integrated solution is a
solution that is rarely implemented.
Here is an old summary of open Canvas a11y issues:
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0237.html
Many of those issues are about CSSOM and are not Canvas-specific. They
came up during WCAG research.
There is another CSSOM shortcut, an extension of SVG pointer events into
HTML:
http://lists.w3.org/Archives/Public/www-svg/2011Apr/0050.html
Those CSSOM issues can be taken up separately from the primary a11y
concerns about legibility and positions.
They are mostly for speed and ease of use. The pointer-events proposal
to www-svg is not for a11y, it's for speed.