Re: hit testing and retained graphics

On Jul 1, 2011, at 1:14 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> On Fri, Jul 1, 2011 at 12:52 PM, Charles Pritchard <chuck@jumis.com> wrote:
>> Richard's proposals have described the secondary purpose of setElementPath as marshaling pointer events directly to the subtree where they would then bubble up as normal. This is constant with keyboard events bubbling up from the subtree. It's also controversial, as the elements in the subtree would retain path information to be used by the UA in delegation of onmouse and onclick events. Vendors would likely re-use hit testing from svg code paths.
> 
> Hm, okay.  How much of this is simple desire for hit-testing, and how
> much is actual desire to retarget clicks to the subtree?  Just wanting
> to uncover the underlying problem that devs are trying to solve, so we
> can solve it well while still smuggling in accessibility.
> 
> ~TJ

They seem to want both hit testing and marshaling, so that they can use familiar addEventListener semantics on elements in the shadow dom.

It is an internally consistent, and coherent solution; it's only minimally invasive because the shadow dom was  already marked out via drawFocusRing for focus/keyboard a11y.

ARIA support still applies here; this allows spatial ATs to glean what role the UI widget has, as well as other data... I want the binding for support of aria/HTML semantics. The canvas devs I've talked with want it for Dom
Events.

That said, canvas devs are low level coders-- they will take notice of any methods made available that relates to their work.

Received on Friday, 1 July 2011 20:23:11 UTC