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. -CharlesReceived on Thursday, 2 February 2012 01:36:21 UTC
This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:47 UTC