On Thu, 15 Mar 2007 20:10:33 +0100, Gareth Hay <[EMAIL PROTECTED]> wrote:
I'm not so sure it is a workaround though.
If you know that the event will bubble, you can make your handler
prevent bubbling.
I don't think we should be adding two new events to a spec, when the
existing events can work in the way you want, albeit with a line more
code. If we did, we'd be forever adding very specialized events.
You don't seem to understand the situation. Imagine there's a parent
element and several child elements. Every time you mouse over a child
element, a mouseover event triggers (and mouseout on the previous
element). This event bubbles up until it reaches the parent element. An
event handler on the parent can only prevent the events from bubbling
event further (which is not relevant), not from reaching itself.
To prevent it using bubble cancelling you would have to attach events
stopping bubbling to every child element of the target. Not only is this
an unreliable way of doing it, it also interferes with potential other
elements which actually want bubbling. The other, more practical
workaround is to look at each incoming event and check "did this one come
bubbling up, or does it belong here". However, workarounds do not solve
the problem itself.
With mouseenter/leave, there is no bubbling. There is no need to attach
handlers to arbitrary elements, and no need to manually check each
incoming event to see if it's bubbling or direct. These events are linked
to a significant enough use case. They are no more redundant than existing
events like click (mousedown+mouseup) and keypress (keydown+keyup).
--
Magnus Kristiansen
"Don't worry; the Universe IS out to get you."
