Re: hit testing and retained graphics

On 6/21/2011 10:20 PM, Cameron McCormack wrote:
> Normalisation of SVG path data doesn’t seem relevant.  (I think you are
> just pointing out that SVG has has DOM objects that represent path
> segment lists.)
Correct.
>> I do not think we need "retained graphics" in canvas -- but it'd be
>> a huge boost to developers,
>> and to accessibility, if we can have a means for sharing path data
>> between layers.
> If you want to be able to store a path to re-use later, what about using
> SVG path data strings?  That doesn’t have the advantage of being an
> object in memory ready for sending to the immediate mode graphics API
> for painting, but it doesn’t sound like your use case needs this.
Yes, that's exactly what I've called for in the stringification 
supplemental;
it'd be a big help to developers, and may be necessary to implement 
internally, for ATs.

It's mentioned as DOMString path and stringify in the CanvasPath interface.

>> Developers have told me that they want mouse events delegated
>> to the shadow dom, based on paths they've bound.
> Can you explain this a bit more?  I didn’t quite follow.  Does it mean
> you want to have it so that
>
>    * you associate an element in the<canvas>  subtree with a particular
>      region of the canvas (by giving it a path, say)
>    * mousedown/mouseup/etc. events get dispatched to the<canvas>  subtree
>      element instead of the<canvas>  itself
That's what they're looking for. I'd be reasonably happy just having 
onclick dispatched;
with Apple's onclick+touch* method extending things further... But yes.. 
they're looking
for mouse events to be dispatched directly to the element in the 
subtree, so they
can do the usual addEventListener things without needing further delegation.

It's not something I've had an issue with as a developer, but multiple 
developers have brought
it up to me as something they think is important.
> So, setElementPath() associates the canvas context’s current path with
> that element.  Apart from the automatic event dispatching thing you
> mention above, what effect does this association have?  (Sorry if this
> is obvious, since I don’t have the context here.)
The information is also sent/retained/made available to assistive 
technology products
for additional heuristics. Apple's VoiceOver is an easy to find example, 
as it is packed
with the iPhone since version 3.x.
>> // Stringify extensions, defined by SVG normalized paths and CSSMatrix.
>> [Supplemental]
>> interface CanvasRenderingContext2D {
>>      void beginFromPath(in normalizedPathSegList path) ;
> There’s no type normalizedPathSegList – that’s the name of a property on
> SVGPathElement objects.  So I guess you mean SVGPathSegList, but as I
> mention above there’s no way to create independent SVGPathSegList
> objects in SVG (at the moment).  You can only grab them off existing
> <path>  elements.
Yes I'm aware. It's an issue to be worked out, consider it a stub for now;
it could be in SVGPathElement, it could be SVGPathSegList; though it can
not be created "independently", it can be created, and has less semantic 
baggage
than SVGElement.

It'd be nice to have some kind of structured object.

>> Stringify options allow developers more room for loose coupling of events;
> I don’t really understand what loose coupling of events means, here.
They don't have to rely on passing private variables or globals, as the data
can be stashed and/or extracted in the DOM.

> How about just using the SVG path data string itself? :-)
It's overly complex; normalized SVG path data strings are nicer to work 
with, both
from implementation side (less complexity) and from developer side (less 
ambiguity; static, verifiable representation).

-Charles

Received on Wednesday, 22 June 2011 22:05:00 UTC