W3C home > Mailing lists > Public > www-dom@w3.org > January to March 1999

Re: DOM II Event Bubbling: DOM-based vs. "view"-based

From: Russ Thomas <russthomas@qsius.com>
Date: Sun, 24 Jan 1999 22:52:11 -0500
Message-ID: <001901be4816$169a3d80$add2cfcf@micron_p166_3.DOMAIN>
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
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" ?

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

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

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:05 UTC