Re: [whatwg] Adding mouseenter and mouseleave events
* Magnus Kristiansen wrote:
Mouseover/out events will trigger when elements contained inside the
EventTarget are hovered, and then bubble up. This is contrary to the most
obvious interpretation, as you are still inside (over) the targeted
element. IE supports two events, mouseenter[1] and mouseleave[2], which
solve this problem by not bubbling.
This actually has little to do with the bubbling behavior but with the
fact that the mouse events are always targeted at the most deeply nested
element, while mouseenter and mouseleave are targeted at all ancestors
not shared by the two relevant event targets. So moving the cursor from
$a to $b you get (in this order):
mouseleave to `$a/ancestor-or-self::* except $b/ancestor-or-self::*`
mouseenter to `$b/ancestor-or-self::* except $a/ancestor-or-self::*`
in, respectively, reverse document order and document order. This means
for example that you get no mouseleave event when moving from an element
to one of its descendants, and no mouseenter event when moving from an
element to one of its ancestors. Calling them mouse-joins-descendant-or-
self-axis and mouse-leaves-descendant-or-self-axis would be clearer.
It is possible to work around the problem by using target/relatedTarget
and walking up the DOM tree. However, this requires extra code for every
event handler. Besides, these events were often not meant to be generated
in the first place, by the intent of the author.
You can simply generate your own events, using document.createEvent(),
and thereby avoid writing code for each handler. You can also use a
general purpose wrapper for your handlers that is registered instead
and decides whether to call the wrapped handler to a similar effect.
For the former you could simply register this brevity-optimized handler
on the document for the capture phase for both mouseover and mouseout:
function (evt) {
var t = [], n = 'mouseenter', b = evt.relatedTarget;
for (var x = evt.target; x; x = x.parentNode)
if (!b || !((x.compareDocumentPosition(b) || 0x10) 0x10))
t.push(x);
if (evt.type == 'mouseout') { n = 'mouseleave'; t = t.reverse(); }
while (t.length) {
var ne = document.createEvent(MouseEvents);
ne.initMouseEvent(n, false, evt.cancelable, evt.view,
evt.detail, evt.screenX, evt.screenY, evt.clientX,
evt.clientY, evt.ctrlKey, evt.altKey, evt.shiftKey,
evt.metaKey, evt.button, evt.relatedTarget);
t.pop().dispatchEvent(ne); } }
In browsers that support the features used above the effect would be
as if they support the two additional events. The code for the other
method would be simpler, as you can see in several script libraries
that support these events in some way.
I have no statistics for how often mouseover/out are used with and without
intent of bubbling, but the anecdotal evidence from my own experience has
never found me wanting it.
Not caring about bubbled up event objects is quite different from the
mouseenter and mouseleave events, you can simply check the .eventPhase
to ignore the former and that you have to do so is a limitation of the
registration system. The mouseenter and mouseleave events have their
own pseudo-bubbling behavior which might let you forget the benefits.
--
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] Adding mouseenter and mouseleave events
I have recently developed an application to identify persons pointed at on a photograph. When person A stands in front of person B the inquirer moves from person A to person B, the application becomes unstable: exit A, enter B, exit B, enter A. It is rather annoying. The person behind should be ignored. Returning false from the handler does not help. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Thursday, May 08, 2008 2:56 AM To: Magnus Kristiansen Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Adding mouseenter and mouseleave events On Thu, 15 Mar 2007, Magnus Kristiansen wrote: Mouseover/out events will trigger when elements contained inside the EventTarget are hovered, and then bubble up. This is contrary to the most obvious interpretation, as you are still inside (over) the targeted element. IE supports two events, mouseenter[1] and mouseleave[2], which solve this problem by not bubbling. It is possible to work around the problem by using target/relatedTarget and walking up the DOM tree. However, this requires extra code for every event handler. Besides, these events were often not meant to be generated in the first place, by the intent of the author. I have no statistics for how often mouseover/out are used with and without intent of bubbling, but the anecdotal evidence from my own experience has never found me wanting it. I suggest these two events be added to the web applications spec. [1] http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onmouseente r.asp [2] http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onmouseleav e.asp I recommend sending this feedback to the WebAPI working group, which is working on DOM events. (I shall forward the thread to the working group, but I do not know if the WebAPI working group has an effective issue tracking mechanism, so you may wish to follow this up to ensure that it gets handled.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding mouseenter and mouseleave events
On Thu, 15 Mar 2007, Magnus Kristiansen wrote: Mouseover/out events will trigger when elements contained inside the EventTarget are hovered, and then bubble up. This is contrary to the most obvious interpretation, as you are still inside (over) the targeted element. IE supports two events, mouseenter[1] and mouseleave[2], which solve this problem by not bubbling. It is possible to work around the problem by using target/relatedTarget and walking up the DOM tree. However, this requires extra code for every event handler. Besides, these events were often not meant to be generated in the first place, by the intent of the author. I have no statistics for how often mouseover/out are used with and without intent of bubbling, but the anecdotal evidence from my own experience has never found me wanting it. I suggest these two events be added to the web applications spec. [1] http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onmouseenter.asp [2] http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onmouseleave.asp I recommend sending this feedback to the WebAPI working group, which is working on DOM events. (I shall forward the thread to the working group, but I do not know if the WebAPI working group has an effective issue tracking mechanism, so you may wish to follow this up to ensure that it gets handled.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding mouseenter and mouseleave events
2007/3/16, Gareth Hay [EMAIL PROTECTED]: Well, the current W3C spec has relatedTarget specifically for these use cases, so again I fail to see why adding convenient shorthand for functionality is a good thing here. If we try to cover everyone's use cases with easy functionality, the spec is going to be huge with lots of overlapping functions and elements. To me this is simply a programming problem, which is easily solved to the use cases suggested, and also the inverse of actually wanting the bubble. Well, there more examples like that that, which are very successful, like .innerHTML. Regards, Martijn Gareth On 16 Mar 2007, at 03:41, Benjamin West wrote: This is a pretty well known issue, and a constant stumbling block. There are use cases for using the capture/bubble stuff[1]. However, by far, the most common need is for simple one-off's, and the bubbling really gets in the way. The issue is explained quite well on PPK's site: http://www.quirksmode.org/js/events_order.html http://www.quirksmode.org/js/events_mouse.html -- covers mouseenter and mouseleave and why it's better (because it explains how tedious the traditional model is first.) The bottom line is that introducing mouseenter and mouseleave will reduce a lot of CPU cycles, and make authoring a lot easier. [1] http://decafbad.com/blog/2006/10/31/event-delegation-based- dhtml-drag-and-drop http://icant.co.uk/sandbox/eventdelegation/ -Ben -- Martijn Wargers Help Mozilla! http://weblogs.mozillazine.org/qa/ http://www.mozilla.org/contribute/
Re: [whatwg] Adding mouseenter and mouseleave events
Is one of the objectives here not to repeat the same mistakes as in the past? Anyway, I seem to be the only descenting voice on this topic, so I suppose I should yield. On 16 Mar 2007, at 09:31, Martijn wrote: 2007/3/16, Gareth Hay [EMAIL PROTECTED]: If we try to cover everyone's use cases with easy functionality, the spec is going to be huge with lots of overlapping functions and elements. To me this is simply a programming problem, which is easily solved to the use cases suggested, and also the inverse of actually wanting the bubble. Well, there more examples like that that, which are very successful, like .innerHTML. Regards, Martijn
Re: [whatwg] Adding mouseenter and mouseleave events
2007/3/16, Gareth Hay [EMAIL PROTECTED]: Is one of the objectives here not to repeat the same mistakes as in the past? What do you mean? Which mistakes? Regards, Martijn
Re: [whatwg] Adding mouseenter and mouseleave events
Well, this is my final word on the subject, it's my opinion, and by the looks of it, only my opinion, but I *personally* don't see the need for changing what we have. I believe that all use cases are currently covered by the W3C spec.I think IMHO that adding 'shorthand' functions, for functionality that already exists, and restricting that functionality adds a barrier of entry to a new developer, and produces a messy outcome. For instance, if you had a 'branding' image for your web sites, and it is always 100px x 100px, that is not good for you to have a new attribute on the img tag for 'branding', so that the image is always rendered 100x100, nor is it good to have a new tag imgbrand that renders the src as 100x100. You simply use the existing img tag and modify it to your specific case. Again, that is *only my opinion*, and final word on the subject. Gareth
Re: [whatwg] Adding mouseenter and mouseleave events
On Fri, 16 Mar 2007 11:35:57 +0100, Gareth Hay [EMAIL PROTECTED] wrote: For instance, if you had a 'branding' image for your web sites, and it is always 100px x 100px, that is not good for you to have a new attribute on the img tag for 'branding', so that the image is always rendered 100x100, nor is it good to have a new tag imgbrand that renders the src as 100x100. You simply use the existing img tag and modify it to your specific case. FWIW: The proposal here is not entirely new. Internet Explorer supports these events. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Adding mouseenter and mouseleave events
Gareth Hay wrote: Maybe your use case requires something different, but I can't imagine that scenario. I ran across this issue the other day, and found this explanation / example which may help clarify the issues people encounter: http://dynamic-tools.net/toolbox/isMouseLeaveOrEnter/ Rob
Re: [whatwg] Adding mouseenter and mouseleave events
It's not a case of not understanding. I fully understand the use case and bubbling, I just don't see this as a problem. On 16 Mar 2007, at 12:29, Rob Crowther wrote: Gareth Hay wrote: Maybe your use case requires something different, but I can't imagine that scenario. I ran across this issue the other day, and found this explanation / example which may help clarify the issues people encounter: http://dynamic-tools.net/toolbox/isMouseLeaveOrEnter/ Rob
Re: [whatwg] Adding mouseenter and mouseleave events
On Thu, 15 Mar 2007 02:02:46 +0100, Gareth Hay [EMAIL PROTECTED] wrote: On 15 Mar 2007, at 00:30, Magnus Kristiansen wrote: Mouseover/out events will trigger when elements contained inside the EventTarget are hovered, and then bubble up. This is contrary to the most obvious interpretation, as you are still inside (over) the targeted element. IE supports two events, mouseenter[1] and mouseleave[2], which solve this problem by not bubbling. It is possible to work around the problem by using target/relatedTarget and walking up the DOM tree. However, this requires extra code for every event handler. Besides, these events were often not meant to be generated in the first place, by the intent of the author. I have no statistics for how often mouseover/out are used with and without intent of bubbling, but the anecdotal evidence from my own experience has never found me wanting it. I suggest these two events be added to the web applications spec. [1] http://msdn.microsoft.com/workshop/author/dhtml/reference/ events/onmouseenter.asp [2] http://msdn.microsoft.com/workshop/author/dhtml/reference/ events/onmouseleave.asp Can't you just return false from an event handler to prevent further bubbling? As mentioned there are workarounds, although I don't think attempting to add anti-bubbling handlers on every descendant element is a reliable one. This unwanted bubbling puts extra load on the user agent for processing it, and the script author to work around it, when removing the root cause is easily possible by making the event non-bubbling to begin with. -- Magnus Kristiansen Don't worry; the Universe IS out to get you.
Re: [whatwg] Adding mouseenter and mouseleave events
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. Mouseover/out events will trigger when elements contained inside the EventTarget are hovered, and then bubble up. This is contrary to the most obvious interpretation, as you are still inside (over) the targeted element. IE supports two events, mouseenter [1] and mouseleave[2], which solve this problem by not bubbling. It is possible to work around the problem by using target/ relatedTarget and walking up the DOM tree. However, this requires extra code for every event handler. Besides, these events were often not meant to be generated in the first place, by the intent of the author. I have no statistics for how often mouseover/out are used with and without intent of bubbling, but the anecdotal evidence from my own experience has never found me wanting it. I suggest these two events be added to the web applications spec. [1] http://msdn.microsoft.com/workshop/author/dhtml/reference/ events/onmouseenter.asp [2] http://msdn.microsoft.com/workshop/author/dhtml/reference/ events/onmouseleave.asp Can't you just return false from an event handler to prevent further bubbling? As mentioned there are workarounds, although I don't think attempting to add anti-bubbling handlers on every descendant element is a reliable one. This unwanted bubbling puts extra load on the user agent for processing it, and the script author to work around it, when removing the root cause is easily possible by making the event non-bubbling to begin with. -- Magnus Kristiansen Don't worry; the Universe IS out to get you.
Re: [whatwg] Adding mouseenter and mouseleave events
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.
Re: [whatwg] Adding mouseenter and mouseleave events
2007/3/15, Magnus Kristiansen [EMAIL PROTECTED]: 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). Yeah, I sort of half remembered a situation where I really had a need for mousenter/mouseleave. I got in a similar situation as you describe. I too think mouseenter/mouseleave events would be a useful addition. Regards, Martijn
Re: [whatwg] Adding mouseenter and mouseleave events
I think I am clearly missing something. If we take your example, a parent element and several child elements. If you want to perform an action on mouseover of a child - attach the event there and cancel bubble. If you want to perform an action on parent mouseover - attach to parent element and check the target of the event. Maybe your use case requires something different, but I can't imagine that scenario. It is not good programming to know that events bubble and not to check the target IMHO anyway. As for redundancy, the keypress event can be distinct from keydown and keyup, in that kepress does not fire for meta-keys, but the other two do, in some browsers. (Although I do admit a consensus in implementation would be good here) On 15 Mar 2007, at 19:51, Magnus Kristiansen wrote: 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.
[whatwg] Adding mouseenter and mouseleave events
Mouseover/out events will trigger when elements contained inside the EventTarget are hovered, and then bubble up. This is contrary to the most obvious interpretation, as you are still inside (over) the targeted element. IE supports two events, mouseenter[1] and mouseleave[2], which solve this problem by not bubbling. It is possible to work around the problem by using target/relatedTarget and walking up the DOM tree. However, this requires extra code for every event handler. Besides, these events were often not meant to be generated in the first place, by the intent of the author. I have no statistics for how often mouseover/out are used with and without intent of bubbling, but the anecdotal evidence from my own experience has never found me wanting it. I suggest these two events be added to the web applications spec. [1] http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onmouseenter.asp [2] http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onmouseleave.asp -- Magnus Kristiansen Don't worry; the Universe IS out to get you.
Re: [whatwg] Adding mouseenter and mouseleave events
Can't you just return false from an event handler to prevent further bubbling? On 15 Mar 2007, at 00:30, Magnus Kristiansen wrote: Mouseover/out events will trigger when elements contained inside the EventTarget are hovered, and then bubble up. This is contrary to the most obvious interpretation, as you are still inside (over) the targeted element. IE supports two events, mouseenter[1] and mouseleave[2], which solve this problem by not bubbling. It is possible to work around the problem by using target/ relatedTarget and walking up the DOM tree. However, this requires extra code for every event handler. Besides, these events were often not meant to be generated in the first place, by the intent of the author. I have no statistics for how often mouseover/out are used with and without intent of bubbling, but the anecdotal evidence from my own experience has never found me wanting it. I suggest these two events be added to the web applications spec. [1] http://msdn.microsoft.com/workshop/author/dhtml/reference/ events/onmouseenter.asp [2] http://msdn.microsoft.com/workshop/author/dhtml/reference/ events/onmouseleave.asp -- Magnus Kristiansen Don't worry; the Universe IS out to get you.
