Re: hit testing and retained graphics

On 6/23/2011 12:56 PM, Richard Schwerdtfeger wrote:
 >
 > Cameron McCormack <cam@mcc.id.au> wrote on 06/22/2011 09:19:15 PM:
 > > Richard Schwerdtfeger:
 > > > Once a path is registered with canvas, the user agent receives 
mouse events
 > > > and assess where they "hit" within the registered draw paths 
(that also
 > > > include Z order) and dispatches the events to the <canvas> 
subtree element.
 > >
 > > Right, so this would need special treatment in the <canvas>
 > > implementation. It feels a bit weird to me, though. What if a region
 > > the canvas is associated with an element that does not have uniform
 > > behaviour across the whole area of that element? I can see it working
 > > OK for a <button>, but for a <select multiple>, say, the exact 
mousedown
 > > position is going to influence what values are going to be selected.
 > >
 > Yes, so, if the select was dropped you would want to create a 
bounding path for the submenu (possibly also for the menu items) and the 
mouse down event would be passed down to the element in the DOM subtree 
to which it was targeted by the user agent as a result of binding the 
path to the element. Should the element not process the mouse event it 
can bubble up to the parent, like it does for HTML today.
 >

Activation/focus of <select> elements is tricky for browser vendors as well.
The area of focus in a select element can differ between vendors / 
operating systems, as there are several
levels of focus.

This kind of situation is documented well by the WAI-ARIA standard, with 
its aria-activedescendant property.

ARIA has excellent support for adding semantic markup to the various 
parts of a listbox (role=listbox, role=combobox)...
The developer may choose to simply insert a <select> element into the 
shadow tree,
and listen on that select element for activation events, and use x/y 
offsets for mouse
events to determine what's happening.

The developer may also decide to use div elements, and bind to 
individual nodes,
which have appropriate ARIA roles set (role=option).

They may also decide to make some kind of crazy select option of their 
own, such as a pie-menu (wheel menu);
as long as the appropriate ARIA (and/or HTML) semantics are in place, 
the DOM and ATs should be fine
with that.

We have an amazing amount of flexibility in the shadow dom thanks to ARIA.

I understand that some vendors and editors would prefer to wait/hope 
until XBL2 solidifies
and receives wide support. I recognize that.. But in the meantime, this 
methodology works,
it works well, and it works in a cost efficient/time efficient manner.

I can speak to that, having implemented <select> in Canvas and having 
implemented
ARIA based interactive widgets.

 > > So normally, I imagine, hit testing would be done either by using
 > > isPointInPath() or by custom code looking at a mouse event’s x/y 
values.
 > > I think this proposal doesn’t work with isPointInPath(), though, is 
that
 > > right?
 > >
 > I think it would but we would need to incorporate Z order and a 
notion of the last drawn element to compute which element is on top. The 
user agent would need to manage this.
 >

The proposal -can- work with isPointInPath; but developers would prefer
that work is handled for them.

For a developer to handle it themselves, they'd want the stringify options:

canvas.onmousemove = function(event) {
     x = processX(event); y = processY(event);
     var z = canvas.querySelectorAll("[data-myeasypathdata]");
     z = sortByZIndex(z);
     for(var element in z) {
         ctx.beginFromPath( element.getAttribute('data-myeasypathdata') );
         if(ctx.isPointInPath(x,y)) { passEvent(element,event); 
if(event.cancelBubble) break; }
     }
};

There's no standard method for sending the path data to the AT.
data-* is simply a private metadata attribute the developer can use.

We're looking to have setElementPath(path, zIndex)
to expose the AT to the path data active on the screen.

These methods, setElementPath, drawFocusRing, greatly encourage Canvas 
developers
to use the shadow DOM+ARIA. They enable Canvas-based widgets to be used
atop of ARIA, and maintain WCAG 2.0 principles.


-Charles

Received on Thursday, 23 June 2011 21:22:08 UTC