Re: hit testing and retained graphics - Reprise

I agree with James, the list does feel toxic.

It's been difficult to find a middle ground between those promoting the 
very obvious issue in a11y
(we just need some floats and strings to be set in the a11y tree, it's 
not hard)
and those promoting SVG as the correct way to handle use cases which 
require spatial/pointer a11y.

It's a large disconnect, I've only seen the use cases themselves lead to 
a tacit  agreement.
The W3C and WhatWG use case listings are reasonably in sync.

Unfortunately, there's no reasonable way to solve the SVG v. Canvas debate.
Any possible response can be met with: "we'll fix that in the SVG standard".
That's been a source of discomfort for me. There is no argument to 
counter the statement, it can't be disproved.

This has rarely been a technical discussion, it's been one about scope 
and ontology. That's unfortunate, this is a technical list,
and when we're actually talking about code, we're able to come up with 
examples and measurable hypothesis.

This isn't code being discussed. I can't see how to work through this.
I do have a vested interest in a Canvas based web applications; I've a 
lot of code,
and I've put over four years of time and resources into them. The 
rebuttals to "rewrite" in
SVG are particularly difficult for me.

The issues about scope seem like a red herring; I'm simply trying to 
support ZoomText
and Apple's VoiceOver, and doing so needs only a small change to the 
existing spec
and implementations.

...

These are the bugs:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13176
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13181

This is a summary of the issue:
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0034.html

This was the discussion in 2009:
http://www.w3.org/html/wg/wiki/ChangeProposals/Map4NotAdom

This is a representative target:
http://www.mozilla.org/access/architecture#MSAA_tree_vs._DOM_tree

These are the use cases:
http://www.w3.org/WAI/PF/HTML/wiki/Canvas_Accessibility_Use_Cases
http://wiki.whatwg.org/wiki/Active_Image_Accessibility_Use-cases

This is the larger tracker:
http://www.w3.org/html/wg/wiki/AddedElementCanvas

This is my light report in June:
http://lists.w3.org/Archives/Public/public-canvas-api/2011AprJun/0041.html
"I've looked at supporting SVG in the Canvas shadow DOM. Unfortunately, 
SVG and HTML forms are not tightly integrated."
There are three audiences for this API:
1. Canvas developers -want- an API for managed mouse events.
2. Existing accessibility APIs, mainly, -need- a means to run
ObjectFromPoint. They -may- want a list of bounding rectangles as well.
3. Some AT devices -need- path information for all interactive objects.

Frank Olivier's suggests simply using CSS box model attributes in the 
sub-dom:
http://lists.w3.org/Archives/Public/public-canvas-api/2011AprJun/0042.html

Benjamin and I agree that re-using the CSS box model would not be a good 
solution:
http://lists.w3.org/Archives/Public/public-canvas-api/2011AprJun/0045.html

My attempt to build on Richard's proposal, introducing two Supplemental 
sets:
http://lists.w3.org/Archives/Public/public-canvas-api/2011AprJun/0047.html

Microsoft takes issue with setElementPath:
http://lists.w3.org/Archives/Public/public-canvas-api/2011AprJun/0070.html
Apple takes issue with setElementPath:
http://lists.w3.org/Archives/Public/public-canvas-api/2011AprJun/0080.html


Representative samples of CanvasRenderingContext2D implementations:
http://trac.webkit.org/browser/trunk/Source/WebCore/html/canvas/CanvasRenderingContext2D.cpp
https://hg.mozilla.org/mozilla-central/file/ec809c159ad2/content/canvas/src/nsCanvasRenderingContext2D.cpp

Most Canvas implementations look quite similar. These are fine examples.
They are built upon low level 2d APIs, and these two include 
boundingRect methods internally.

We are primarily trying to expose the boundingRect data to the 
Accessibility Tree,
when the author finds it to be an appropriate time.

The secondary objective has been to give the author a way to access path 
data
via DOMString and/or via an opaque object -- this corresponds with how 
path data
is managed by the underlying 2d apis. They have path objects stashed 
internally.

Along with that objective, we've looked at marshaling pointer events 
into the sub-dom, as is currently done with keyboard events.
Doing so will encourage canvas authors to use the sub-dom and bind it to 
paths via setElementPath.


That's the situation.

-Charles


On 7/8/2011 1:32 PM, James Robinson wrote:
>
> On Fri, Jul 8, 2011 at 1:25 PM, Richard Schwerdtfeger 
> <schwer@us.ibm.com <mailto:schwer@us.ibm.com>> wrote:
>
>
>     Have you heard from Microsoft, Apple, or Google that they would
>     support this approach? If so, I am all in. I mean if you are going
>     to put in all this work on canvas-svg integration I would try to
>     get some buy in on the approach to start. This is why I have
>     avoided prototyping hit testing in canvas. Frankly, the hit
>     testing is not terribly hard to do but like you I have a lot of
>     demands on my time.
>
>
> To be perfectly frank, speaking only for myself and not for other 
> people at Google or in the Chromium project, I've been reluctant to 
> chime in on these threads because it seems that everyone who does gets 
> flamed out within a few messages.  If this mailing list was not so 
> toxic I suspect there would be a broader, more productive discussion. 
>  That said, I'm confident that Doug's proposal will be given due 
> consideration by the proper people at the proper time.
>
> - James
>