Re: hit testing and retained graphics

On 7/7/2011 12:05 PM, Doug Schepers wrote:
>>> (I could see a solution where this isn't the case, and the DOM
>>> actually *does* act as a form of scene graph, but that probably
>>> requires a new context to be written. It's also remarkably similar to
>>> Doug's proposal to put Canvas in SVG.)
>
> A better characterization of my proposal is to have a shared API that 
> makes it equally easy for an author to create an SVG element or a 
> Canvas shape, and an extension to the Canvas subtree stuff that points 
> to any SVG elements thus created.  But yes, I'd like to be able to use 
> Canvas in SVG, where appropriate.
I'd love to have Canvas added to the public-fx charter.
The Canvas+CSS profile is functioning well, FX is currently
working on CSS+SVG; I'd like to see CSS+SVG+Canvas.

There continue to be several apis which reasonably fall in that scope:
mozRequestAnimationFrame, and css canvas contexts. Is there room in FX
for this discussion? It seems relevant.

>
> SVG saves the state automatically as part of its logical and rendering 
> models.  Canvas "forgets" the state.  You are proposing to add 
> functionality to have Canvas save the state, either automatically or 
> by author action.
SVG retains the state for further use by the developer. I'm proposing 
that Canvas -send- the current state
immediately to the accessibility API. This is already done with 
drawFocusRing; the only difference here is
that the information sent by drawFocusRing is presumed stale when focus 
changes.

Information from setElementPath is presumed stale when the node is 
removed from the shadow dom.

It's not canvas that's saving the state, it's only sending the state to 
the accessibility classes.
The UA retains information necessary for the accessibility implementation,
that information is not exposed to the scripting environment.

It's not retained in the canvas implementation nor in the canvas 
element. From the point of view
of the canvas implementation, canvas is still immediate mode. It knows 
nothing about the shadow dom
and the scripting environment has no way to access the accessibility tree.

> There are two open questions this raises:
> 1) Should we expose this "state information" somehow?
> 2) How should we do it?
>
> I think the answer to (1) is "yes", for at least some limited set of 
> cases [1].
>
> I think the answer to (2) does not yet have consensus, but lets not 
> keep pretending that the answer to (1) is the answer to (2), or that 
> browser vendors are necessarily objecting to (1).
>
> [1] http://www.w3.org/WAI/PF/HTML/wiki/Canvas_Accessibility_Use_Cases

I don't understand the distinction you're making when you say:
"I think the answer to (1) is 'yes'... lets not keep pretending that the 
answer to (1) is the answer to (2)".

Elements in the shadow dom require at minimum a description of their 
boundaries, to achieve the most basic compatibility
with platform accessibility APIs.  drawFocusRing illustrates exactly how 
this can be achieved. We're simply trying
to add a second method which works regardless of whether the element has 
active focus.

Received on Wednesday, 13 July 2011 07:06:18 UTC