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

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

From: Keith Bernstein <keith.bernstein@Eng.Sun.COM>
Date: Sun, 24 Jan 1999 20:09:11 -0800
Message-ID: <36ABEE67.CA45946B@eng.sun.com>
To: Russ Thomas <russthomas@qsius.com>
CC: www-dom@w3.org
Russ -

I'm not sure what to address first in your reply, but either I wasn't
very clear, or you misunderstood a lot of my posting.

> 1 - bubbling up means bubbling up.  Not left/right east/west... or, worse, up
> one, down one, up one down one... ad infinitum.

But it *wouldn't* be left/right/etc in the *visual/view* hierarchy. It
would be from "top-most" z-ordered child to "back-most" parent. This is
the way most GUI operating systems work.

> 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.

No, the only nodes which would be "walked" are nodes which are known, by
the "displayer" to be "underneath" the mouse.

> 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.

Using layers it will be possible to lay a transparent "sheet" over a
whole page. That sheet will not be the HTML ancestor of what it covers,
which means, based on the current model, users could not "click-through"
it to the buttons, etc., below 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!  :-)

As I mentioned above, what I've suggested is no more complicated than
walking a DOM tree... it's a simple matter of walking a visible/view
containment hierarchy.

> what is your definition of "subsequent nodes" ?

Whatever node is "next" in the bubbling up.

> 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.
> ==

Didn't mean to offend you here. This was not meant as a cut on MS, IE,
or on w3c. What I mean by "stuck", and I think w3c members would agree
with this, is that for good or bad there are millions of web pages
written to MS' event model, so whatever the w3c proposes needs to be as
consistent with that as possible. It happened with DOM I, CSS, etc.,
etc. This is a fact of the web-standards world... most future standards
need to take into account existing standards, be they defacto, or
otherwise.

> Well it does work in IE4 on a PC (even though the HTML has a broken IMG
> element).

Yes, my mail said that it *only* works on IE, so it makes sense that it
would work on IE ??? WRT the broken IMG element... it's not broken, it's
what I intended. This was just a simple example to show what I wanted to
show. Just pretend the images are any kind of "view" you like, a button,
a textfield, an image, whatever. It's really irrelevant for the point
I'm tyring to make.

> 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).

As I said above, this wasn't an example in how to write proper or
meaningful HTML... I just whipped something up that would show how
siblings can overlap eachother. Don't focus so much on the details...
focus on the *concepts*.

kb

Russ Thomas wrote:
> 
> 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 23:12:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:46 GMT