- From: Russ Thomas <russthomas@qsius.com>
- Date: Sun, 24 Jan 1999 22:52:11 -0500
- To: <www-dom@w3.org>
Keith Bernstein wrote: The DOM II spec defines event bubbling as bubbling up through the DOM tree, not the user-visible "view" tree. I don't believe this is correct, though Microsoft's IE behaves this way, so the DOM II rec. likely won't/can't/shouldn't change. In any case, I thought I would explain why I feel bubbling through the DOM hierarchy is incorrect. Not using the user-visible "view" hierarchy to "bubble" events is a mistake, because if it's not used, then if the visible "view" of one element[node] overlayed the "view" of a *sibling* (for example), when the mouse was pressed, if the top-most element didn't handle it, the sibling below it would never get a shot at it because it would next go to the *DOM-parent* of the clicked element. Event dispatching is all about getting a user action (e.g. a mouseclick) to the "right" widget/element, which, for the user, is some element which is visually under the mouse (regardless of its position in the DOM hierarchy) not its DOM parent (which could be on the other side of the screen from the clicked-on child element). ======== couple of points: 1 - bubbling up means bubbling up. Not left/right east/west... or, worse, up one, down one, up one down one... ad infinitum. 2 - you mentioned the "right widget/element"... if your green element is the "right element", then, in this circumstance, you (as the designer) have shown scant (no?) regard for handling an event deemed important to you. Why blame the DOM? 3 - to suggest that an event model should walk siblings "in case" they overlap, would (I believe) introduce a considerable amount of sanity checking code, not to mention the code required to actually *do* something. 4 - your green (child of red) is not part of the blue decendent tree. Blue has no "business" knowing about clicks on green as you have designed it. Going back to points 1 and 3, would not your theory require sending the event to ALL possible siblings... *and* their decendents? Maaan - stop the DOM, I wanna get off! :-) == Yes, the DOM doesn't know about user actions, but nevertheless, it does take a starting node, and that starting node is based on where the "visual view" is when the mouse is pressed, so why shouldn't subsequent nodes' "view" positions be used to bubble the event? ========= what is your definition of "subsequent nodes" ? == <snip> Imagine, for example, that the "lower" element is a custom button, and the "overlayed element" is an icon on the button (and both have been placed with absolute positioning). If that were the case, clicking the button's image would not cause the button's action method to be called, because the button is a sibling, not a parent. ========== and rightly so - because in the design as depicted the click is *not* an event on "the button's image". The button does not *have* an image... if I read the forma correctly, "red" has an image as does the document. Another point; Your text talks about absolute positioning and your example (unless I'm very much mistaken) does something completely different. Were you to *use* absolute positioning, then that would be a *choice* you made, not a mandate from above. By removing an element from the flow, you *are* losing (in most cases?) the benefit of the heirarchy. (Correct me if I'm wrong somebody, I'm a complete newbie here :-)) == As I said above, Microsoft's IE behaves the way the DOM II spec defines bubbling, so deviations would cause incompatibilities, making this more of a theoretical point than a practical one, since we are stuck with the current situation. ========== stuck? Please, I for one am very happy with it... and look forward to it maturing. Sensibly. == Here is very small JavaScript example (only works in IE) which shows why DOM-based event bubbling can do the "wrong" thing, and why view-based bubbling, by definition, always does the right thing: ========= Well it does work in IE4 on a PC (even though the HTML has a broken IMG element). In the time it has taken me to read/test/fix/reply (aren't examples great? :-)) I now see where you're going. Trying to use a self contained container (ie an IMG) as a container for other containers (especially in a container-oriented DOM) is (IMHO) a recipe for disaster. Why not *use* a *container*? eg: a DIV ? ie, make BLUE a DIV and truly contain the IMG (green) then everything works. No need to absolutely position anything (which you weren't doing anyway). <div id="blue" .....> <img id="green" ....> </div> or, dare I mention it, for IE: <button id="blue" .....> <img id="green" ....> </button> Russ Thomas
Received on Sunday, 24 January 1999 22:49:18 UTC