Adding mouseenter and mouseleave events

Forwarded message 1

• From: Magnus Kristiansen <magnusrk+whatwg@pvv.org>
• Date: Thu, 15 Mar 2007 01:30:13 +0100
• Subject: [whatwg] Adding mouseenter and mouseleave events
• To: whatwg@whatwg.org
• Message-ID: <op.to7fonch6iodd8@tzeentch.studby.ntnu.no>

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

Forwarded message 2

• From: Magnus Kristiansen <magnusrk+whatwg@pvv.org>
• Date: Thu, 15 Mar 2007 12:25:52 +0100
• Subject: Re: [whatwg] Adding mouseenter and mouseleave events
• To: "Gareth Hay" <gazhay@gmail.com>
• Cc: whatwg@whatwg.org
• Message-ID: <op.to791efl6iodd8@tzeentch.studby.ntnu.no>

On Thu, 15 Mar 2007 02:02:46 +0100, Gareth Hay <gazhay@gmail.com> 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."

Forwarded message 3

• From: Gareth Hay <gazhay@gmail.com>
• Date: Thu, 15 Mar 2007 19:10:33 +0000
• Subject: Re: [whatwg] Adding mouseenter and mouseleave events
• To: Magnus Kristiansen <magnusrk+whatwg@pvv.org>
• Cc: whatwg@whatwg.org
• Message-Id: <677B8BFC-96D5-4DCD-A987-688316603812@gmail.com>

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

Forwarded message 4

• From: Magnus Kristiansen <magnusrk+whatwg@pvv.org>
• Date: Thu, 15 Mar 2007 20:51:58 +0100
• Subject: Re: [whatwg] Adding mouseenter and mouseleave events
• To: "Gareth Hay" <gazhay@gmail.com>
• Cc: whatwg@whatwg.org
• Message-ID: <op.to8xgwcb6iodd8@tzeentch.studby.ntnu.no>

On Thu, 15 Mar 2007 20:10:33 +0100, Gareth Hay <gazhay@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."

Forwarded message 5

• From: Martijn <martijn.martijn@gmail.com>
• Date: Thu, 15 Mar 2007 20:59:32 +0100
• Subject: Re: [whatwg] Adding mouseenter and mouseleave events
• To: "Magnus Kristiansen" <magnusrk+whatwg@pvv.org>
• Cc: whatwg@whatwg.org, Gareth Hay <gazhay@gmail.com>
• Message-ID: <6c97b8b10703151259u6a7e6eb8m830e5a6568b55af8@mail.gmail.com>

2007/3/15, Magnus Kristiansen <magnusrk+whatwg@pvv.org>:
>
> On Thu, 15 Mar 2007 20:10:33 +0100, Gareth Hay <gazhay@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).



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

Forwarded message 6

• From: Gareth Hay <gazhay@gmail.com>
• Date: Thu, 15 Mar 2007 20:05:34 +0000
• Subject: Re: [whatwg] Adding mouseenter and mouseleave events
• To: Magnus Kristiansen <magnusrk+whatwg@pvv.org>
• Cc: whatwg@whatwg.org
• Message-Id: <5836BC09-8364-43CE-B568-5878E11B10CC@gmail.com>

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 <gazhay@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."

Forwarded message 7

• From: Gareth Hay <gazhay@gmail.com>
• Date: Fri, 16 Mar 2007 07:41:49 +0000
• Subject: Re: [whatwg] Adding mouseenter and mouseleave events
• To: Benjamin West <bewest@gmail.com>
• Cc: WHATWG List <whatwg@whatwg.org>
• Message-Id: <802E5523-339F-4B34-ADBD-25B7DC01B689@gmail.com>

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.

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

Forwarded message 8

• From: Martijn <martijn.martijn@gmail.com>
• Date: Fri, 16 Mar 2007 10:31:19 +0100
• Subject: Re: [whatwg] Adding mouseenter and mouseleave events
• To: "Gareth Hay" <gazhay@gmail.com>
• Cc: WHATWG List <whatwg@whatwg.org>, Benjamin West <bewest@gmail.com>
• Message-ID: <6c97b8b10703160231t5abfe0bdx778df4527fc3916a@mail.gmail.com>

2007/3/16, Gareth Hay <gazhay@gmail.com>:
>
> 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/

Forwarded message 9

• From: Gareth Hay <gazhay@gmail.com>
• Date: Fri, 16 Mar 2007 09:36:01 +0000
• Subject: Re: [whatwg] Adding mouseenter and mouseleave events
• To: Martijn <martijn.martijn@gmail.com>
• Cc: WHATWG List <whatwg@whatwg.org>, Benjamin West <bewest@gmail.com>
• Message-Id: <9DE83AD0-CDD6-4A5F-829B-6AB8B61638ED@gmail.com>

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 <gazhay@gmail.com>:
>
> 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
>
>
>

Forwarded message 10

• From: Martijn <martijn.martijn@gmail.com>
• Date: Fri, 16 Mar 2007 10:40:38 +0100
• Subject: Re: [whatwg] Adding mouseenter and mouseleave events
• To: "Gareth Hay" <gazhay@gmail.com>
• Cc: WHATWG List <whatwg@whatwg.org>, Benjamin West <bewest@gmail.com>
• Message-ID: <6c97b8b10703160240m31468aefob47da110e7847f1@mail.gmail.com>

2007/3/16, Gareth Hay <gazhay@gmail.com>:
>
> Is one of the objectives here not to repeat the same mistakes as in the
> past?
>

What do you mean? Which mistakes?

Regards,
Martijn

Forwarded message 11

• From: Gareth Hay <gazhay@gmail.com>
• Date: Fri, 16 Mar 2007 10:35:57 +0000
• Subject: Re: [whatwg] Adding mouseenter and mouseleave events
• To: Martijn <martijn.martijn@gmail.com>
• Cc: WHATWG List <whatwg@whatwg.org>
• Message-Id: <2F21F7D7-2200-4C18-B44F-B2163077BA89@gmail.com>

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

Forwarded message 12

• From: Anne van Kesteren <annevk@opera.com>
• Date: Fri, 16 Mar 2007 12:03:37 +0100
• Subject: Re: [whatwg] Adding mouseenter and mouseleave events
• To: "Gareth Hay" <gazhay@gmail.com>, Martijn <martijn.martijn@gmail.com>
• Cc: WHATWG List <whatwg@whatwg.org>
• Message-ID: <op.to93ob0264w2qv@id-c0020.driveway.uu.nl>

On Fri, 16 Mar 2007 11:35:57 +0100, Gareth Hay <gazhay@gmail.com> 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/>

Forwarded message 13

• From: Rob Crowther <robertc@boogdesign.com>
• Date: Fri, 16 Mar 2007 12:29:31 +0000
• Subject: Re: [whatwg] Adding mouseenter and mouseleave events
• To: whatwg@whatwg.org
• Message-ID: <45FA8DAB.9030708@boogdesign.com>

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

Forwarded message 14

• From: Gareth Hay <gazhay@gmail.com>
• Date: Fri, 16 Mar 2007 12:45:27 +0000
• Subject: Re: [whatwg] Adding mouseenter and mouseleave events
• To: Rob Crowther <robertc@boogdesign.com>
• Cc: whatwg@whatwg.org
• Message-Id: <965DB2AD-E217-4470-ACF7-6AD629420567@gmail.com>

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