Re: hit testing and retained graphics

On 6/23/2011 8:07 PM, Cameron McCormack wrote:
> 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)?
It's up to the script author to detect focus and activation of the 
select element,
and in doing so, change its appearance and its associated path data;
the same holds true for child objects of the select element in the world 
of ARIA;
though in HTML5, child elements are opaque.

Keep to the concept of "implementing", instead of "emulating".

The issue with emulating is primarily that different OS vendors
have different behaviors on opaque objects, such as the window
that pops up when select menus are activated. You'll notice on
some UA implementations, the select menu can reach-outside of the 
bounding box
of the UA window.

> 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.)
Example provided below; it is not -necessary- in the original proposal, 
but is fully supported.
>> 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.
Yes, I brought it to SVG looking for feedback and possible re-use.
If it's in the DOM, ATs can see it. If it's not in the DOM, but it's sent
via method call, ATs can see it. It's imperative that ATs can see it.

In talking with various developers, and in line with the motivations
of many spec editors and vendors, it seems that adding functionality,
such as the binding methods we've put forward, creates more incentive
for all parties to include the methods.

The stringify is sufficient, in a technical sense; but adding methods which
implement more detailed event handling do make room for more efficient
implementations, more encouragement for developers to use them, and
seemingly, more reasons for spec editors to support them.

So, I've put them forward in two pieces.

There's still significant push-back in allowing the vocabulary
necessary to make paths accessible in the first place. Unfortunately.


Received on Friday, 24 June 2011 03:31:19 UTC