- From: Magnus Kristiansen <magnusrk+whatwg@pvv.org>
- Date: Thu, 15 Mar 2007 20:51:58 +0100
On Thu, 15 Mar 2007 20:10:33 +0100, Gareth Hay <gazhay at gmail.com> 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."
Received on Thursday, 15 March 2007 12:51:58 UTC