Looking at the DOM 2 Events spec (http://tinyurl.com/e2twx), here's the relevant paragraph on event targeting:
So it is up to the DOM implementation to determine the initial EventTarget. In the browser case, clearly the initial EventTarget is taken as the frontmost view whether or not a relevant event handler is installed on that view. (This behavior is consistent with every desktop GUI framework I've ever seen.) The rest of the behavior we see follows: capture and bubbling only apply to the EventTarget's parent chain up to the Document so you'll never see targeting of views that are visually behind the EventTarget but are not an ancestor of that target. So we've got two realistic choices: adopt the DOM2 targeting model in Flash, or adopt the Flash model in all other runtimes. Based on principles alone I would favor the former, but I admit I don't know what impact this would have on existing OL applications. There is a way of adopting the Flash model that we haven't yet pursued (I don't think) -- using the event capture phase to essentially re-implement targeting. So we force event capture, and from the document down redirect the event where we want it. But we'd still need a quadtree or something to know where to redirect the event. However, this imposes overhead on all DOM2 runtimes (HTML, SVG, ...) in order to support what will over time increasingly appear to be an oddball behavior inherited from Flash. I guess the first question is what the impact of adopting DOM2 event targeting would be on existing code. Anyone want to investigate this? jim On Sep 13, 2006, at 9:25 AM, Jim Grandy wrote: Moving thread to laszlo-dev. |
_______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
