Re: hit testing and retained graphics

Cameron McCormack:
> > > 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.

Charles Pritchard:
> 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.

I think I may have misunderstood the proposal, but I am a bit confused
now.  Clicking on the canvas at a particular point that has been
associated with the <select> wouldn’t cause the native <select> element
to have its menu drop down, then, or cause any change in what selected
value is?  Is it up to the script author to listen for a mousedown/
mouseup event on the <select> and modify its value in response to that
(emulating the native behaviour of the element)?

Cameron McCormack:
> > > 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?

Richard Schwerdtfeger:
> > 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.

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

(Can as in could be modified to work with isPointInPath, yeah?  Because
I didn’t see anything in the original proposal about it.)

> 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.

I wonder if (and maybe this is similar to what we discussed earlier on
www-svg) having an aria-region (or whatever named) attribute on the
shadow tree element is a simpler, more direct way of associating the
region of the <canvas> that has the focus.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Friday, 24 June 2011 03:08:10 UTC