Re: Request to re-open issue 131 -USE CASES, USE CASES, USE CASES

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