FW: [Adding mouseenter and mouseleave events]

I wanted to note the following was posted to the public-webapi
list last month but as far as I can see, nobody ever replied to
it. So I'm wondering what the status is on the request. Has there
been further discussion about this on telcons or IRC? Is it
something that's being considered or incorporation in the DOM3
Events spec?

  --Mike

----- Forwarded message from Ian Hickson <ian@hixie.ch> -----

Date: Thu, 8 May 2008 00:58:04 +0000 (UTC)
From: Ian Hickson <ian@hixie.ch>
To: public-webapi@w3.org
Archived-At: <http://www.w3.org/mid/Pine.LNX.4.62.0805080055450.9075@hixie.dreamhostps.com>
Subject: Adding mouseenter and mouseleave events


The WHATWG received the attached feedback. It's not clear to me which 
specification should be defining the normative requirements on events like 
mouseover, mousemove, mouseout, and so forth, let alone who would specify 
new events as requested in this feedback.

Will the DOM3 Events specification include such requirements? (Right now 
it has nothing resembling normative requirements for these events.)

Please let me know if this is not something that DOM3 Events will handle, 
so that I can find a more suitable working group for this feedback.

Thanks,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Content-Description: [whatwg] Adding mouseenter and mouseleave events (fwd)
To: whatwg@whatwg.org
From: Magnus Kristiansen <magnusrk+whatwg@pvv.org>
Date: Thu, 15 Mar 2007 01:30:13 +0100
User-Agent: Opera Mail/9.20 (Win32)
Subject: [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."

Content-Description: Re: [whatwg] Adding mouseenter and mouseleave events (fwd)
Date: Thu, 15 Mar 2007 12:25:52 +0100
To: Gareth Hay <gazhay@gmail.com>
From: Magnus Kristiansen <magnusrk+whatwg@pvv.org>
User-Agent: Opera Mail/9.20 (Win32)
Cc: whatwg@whatwg.org
Subject: Re: [whatwg] Adding mouseenter and mouseleave events


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

Content-Description: Re: [whatwg] Adding mouseenter and mouseleave events (fwd)
From: Gareth Hay <gazhay@gmail.com>
Date: Thu, 15 Mar 2007 19:10:33 +0000
To: Magnus Kristiansen <magnusrk+whatwg@pvv.org>
X-Mailer: Apple Mail (2.752.3)
Cc: whatwg@whatwg.org
Subject: 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."


Content-Description: Re: [whatwg] Adding mouseenter and mouseleave events (fwd)
Date: Thu, 15 Mar 2007 20:51:58 +0100
To: Gareth Hay <gazhay@gmail.com>
From: Magnus Kristiansen <magnusrk+whatwg@pvv.org>
User-Agent: Opera Mail/9.20 (Win32)
Cc: whatwg@whatwg.org
Subject: Re: [whatwg] Adding mouseenter and mouseleave events


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

Content-Description: Re: [whatwg] Adding mouseenter and mouseleave events (fwd)
Date: Thu, 15 Mar 2007 20:59:32 +0100
From: Martijn <martijn.martijn@gmail.com>
To: Magnus Kristiansen <magnusrk+whatwg@pvv.org>
Cc: whatwg@whatwg.org, Gareth Hay <gazhay@gmail.com>
Subject: Re: [whatwg] Adding mouseenter and mouseleave events

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

Content-Description: Re: [whatwg] Adding mouseenter and mouseleave events (fwd)
From: Gareth Hay <gazhay@gmail.com>
Date: Thu, 15 Mar 2007 20:05:34 +0000
To: Magnus Kristiansen <magnusrk+whatwg@pvv.org>
X-Mailer: Apple Mail (2.752.3)
Cc: whatwg@whatwg.org
Subject: 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 <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."


Content-Description: Re: [whatwg] Adding mouseenter and mouseleave events (fwd)
From: Gareth Hay <gazhay@gmail.com>
Date: Fri, 16 Mar 2007 07:41:49 +0000
To: Benjamin West <bewest@gmail.com>
X-Mailer: Apple Mail (2.752.3)
Cc: WHATWG List <whatwg@whatwg.org>
Subject: Re: [whatwg] Adding mouseenter and mouseleave events


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


Content-Description: Re: [whatwg] Adding mouseenter and mouseleave events (fwd)
Date: Fri, 16 Mar 2007 10:31:19 +0100
From: Martijn <martijn.martijn@gmail.com>
To: Gareth Hay <gazhay@gmail.com>
Cc: WHATWG List <whatwg@whatwg.org>, Benjamin West <bewest@gmail.com>
Subject: Re: [whatwg] Adding mouseenter and mouseleave events

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/

Content-Description: Re: [whatwg] Adding mouseenter and mouseleave events (fwd)
From: Gareth Hay <gazhay@gmail.com>
Date: Fri, 16 Mar 2007 09:36:01 +0000
To: Martijn <martijn.martijn@gmail.com>
X-Mailer: Apple Mail (2.752.3)
Cc: WHATWG List <whatwg@whatwg.org>, Benjamin West <bewest@gmail.com>
Subject: 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 <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
>
>
>


Content-Description: Re: [whatwg] Adding mouseenter and mouseleave events (fwd)
Date: Fri, 16 Mar 2007 10:40:38 +0100
From: Martijn <martijn.martijn@gmail.com>
To: Gareth Hay <gazhay@gmail.com>
Cc: WHATWG List <whatwg@whatwg.org>, Benjamin West <bewest@gmail.com>
Subject: Re: [whatwg] Adding mouseenter and mouseleave events

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

Content-Description: Re: [whatwg] Adding mouseenter and mouseleave events (fwd)
From: Gareth Hay <gazhay@gmail.com>
Date: Fri, 16 Mar 2007 10:35:57 +0000
To: Martijn <martijn.martijn@gmail.com>
X-Mailer: Apple Mail (2.752.3)
Cc: WHATWG List <whatwg@whatwg.org>
Subject: 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

Content-Description: Re: [whatwg] Adding mouseenter and mouseleave events (fwd)
To: Gareth Hay <gazhay@gmail.com>, Martijn <martijn.martijn@gmail.com>
From: Anne van Kesteren <annevk@opera.com>
Date: Fri, 16 Mar 2007 12:03:37 +0100
User-Agent: Opera Mail/9.10 (Win32)
Cc: WHATWG List <whatwg@whatwg.org>
Subject: Re: [whatwg] Adding mouseenter and mouseleave events


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

Content-Description: Re: [whatwg] Adding mouseenter and mouseleave events (fwd)
Date: Fri, 16 Mar 2007 12:29:31 +0000
From: Rob Crowther <robertc@boogdesign.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
To: whatwg@whatwg.org
Subject: 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

Content-Description: Re: [whatwg] Adding mouseenter and mouseleave events (fwd)
From: Gareth Hay <gazhay@gmail.com>
Date: Fri, 16 Mar 2007 12:45:27 +0000
To: Rob Crowther <robertc@boogdesign.com>
X-Mailer: Apple Mail (2.752.3)
Cc: whatwg@whatwg.org
Subject: 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




----- End forwarded message -----

-- 
Michael(tm) Smith
http://people.w3.org/mike/
http://sideshowbarker.net/