On 2/1/2012 4:29 PM, Frank Olivier wrote:
> I don't understand - What would a valid use case for nesting canvas
> elements? In my opinion, this would not be a valid case...
>
>
> On 15 Jan 2012, at 07:08, Benjamin Hawkes-Lewis wrote:
>
>> * Especially, bearing in mind that <canvas> objects could be nested
>> and that events could be forwarded outside of the <canvas>, is there
>> any way of determining what <canvas> element received the forwarded
>> event?
>
We've put canvas elements inside of other canvas elements simply to have
them in the DOM. But we've never nested UI inside of those nested elements.
The event is intended to bubble straight from the UI element. So the
behavior of these is about the same:
<div><button onclick /></div>
<canvas><button onclick /></canvas>
<div><div><button onclick /></div></div>
<canvas><canvas><button onclick /></canvas></canvas>
I guess someone could do this:
<canvas id=can1><canvas id=can2><button id=but1 onclick /></canvas></canvas>
ctx1.setElementPath(can2);
ctx2.setElementPath(but1);
I've never seen anything like that in the wild, but it seems like
implementations would support that, if they picked up the event
forwarding proposal.
In real-world use, with scripted hit we've done something like this,
sometimes for widgets, and sometimes for efficiency.
The first level is just a bounding box, the second level is a complex shape.
But with dom, we've added elements into a nested canvas element.
As for the relatedTarget, I don't know that it's necessary to include
it. The author already knows which canvas they used when they bound to
the sub-element. It's also the case that a click event may happen
directly on the element, via tabfocus. So, I don't see using
relatedTarget as something that would be reliable or necessary.
-Charles