Re: hit testing and retained graphics

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

Charles Pritchard:
> Yes, that's exactly what I've called for in the stringification
> supplemental;

Sorry, I meant solely a DOMString, rather than using an opaque object to
represent the path.

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

As I just mentioned in my reply to Rich, I’m concerned this works only
for very simple cases, like buttons.  Any mouse input that is more
complex than “a click anywhere in the region is the same as a click
anywhere on the corresponding subtree element” doesn’t seem to work with
this model.  The visual presentation of the in-canvas version of the
form control could be greatly different, and have different behaviour,
from the real form control.

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

But does that do anything with the area on the canvas information, or
just the fact that the subtree element is focussed?  I would’ve thought
that the regular focussing mechanism is used to indicate whether a
particular subtree element is active or not.

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

True, you don’t want to pass in an SVG <path> element if all you want to
pass in is path data.

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

Maybe.  I think it’s something the SVG WG will consider for SVG 2.0.
(At least, the current SVG DOM needs some work to be more usable.)  But
I think for your purposes you don’t need the structure; all you’re doing
is passing a whole path to a method.

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

Is it that since the opaque path objects have stringifiers, you can put
these strings directly on attributes in the DOM?  I guess that could be
helpful, but you can also just put expando properties on the DOM objects
if you needed more than a string.

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

Maybe we’re using different meanings for “normalised” here?

In SVG, paths can be represented in their original form or a normalised
form.  In the normalised form, arc commands are replaced with sequences
of Bézier curves or straight line segments, shorthand commands like H
and V are converted to single straight line segments, all relative commands
converted to absolute, and so on.  (No exact algorithm is required.)  So
a path in its original form might be

  M10,10 h100 A50,50 0 0 0 160,60

and in normalised form

  M10,10 L110,10 C… C… C…

if it decomposes the arc into curves.  Anyway, you would need the full
SVG path syntax to represent the kinds of paths that you can construct
with canvas, since you have the arcTo method.

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

Received on Thursday, 23 June 2011 02:46:02 UTC