#350 ✓resolved
Nick Stakenburg

Add mouseenter and mouseleave support to Event#observe

Reported by Nick Stakenburg | September 20th, 2008 @ 04:17 AM | in 1.7

This patch will allow Event#observe to handle mouseenter and mouseleave events. Having this available in Core will be very useful for plugin authors. Currently we're having to hack something similar into every individual plugin, not ideal. Hopefully this can be considered for 1.6.1.


$(element).observe('mouseenter', function() { alert('entered'); });
$(element).observe('mouseleave', function() { alert('left'); });

Demo: http://nickstakenburg.com/tests/...

My patch is based on code I've been using successfully in Prototip for some months. I've tested Woil's patch from the old trac and experimented with the Mootools approach but both cause problems with inputs, textareas and the browser autocomplete feature. jQuery has a better approach using a try/catch to work around these problems. This patch is based on jQuery and Woil's approach.

There has been some discussion about implementing this as custom events. Besides that I don't see that happening anytime soon because custom events always bubble, the whole power behind mouseenter mouseleave events is that they don't bubble, this approach is better then using custom events. It avoids keeping track of every mouse event on the page by only observing what's needed, so this takes a lot less work for the browser. Nothing wrong with custom events but we shouldn't use them for the sake of using custom events, usage like dom:loaded is good but custom events are not the best approach for mouseenter mouseleave.

Tested on: IE6, IE7, FF2, FF3, Opera9.25+, Safari

Comments and changes to this ticket

  • Tobie Langel

    Tobie Langel September 27th, 2008 @ 09:47 PM

    • State changed from “new” to “enhancement”
  • Juriy Zaytsev

    Juriy Zaytsev October 3rd, 2008 @ 07:26 PM

    I desperately believe we must have this in a core (or some kind of variation of it)

    +1

  • Andrew Dupont

    Andrew Dupont October 3rd, 2008 @ 10:43 PM

    • Milestone set to 1.7
    • Tag changed from events, patched to discuss, events

    I'm still planning to implement this with custom events, since we'll have support for non-bubbling custom events in 1.6.1.

    Nick, I understand your argument that a custom events approach is a bad idea; I think we just have different priorities. I promise I'll do some performance testing of my "listen on the whole document" solution to make sure it's performant. This is going to be in 1.6.1 one way or another.

    Anyone else want to weigh in on this?

  • Andrew Dupont

    Andrew Dupont October 3rd, 2008 @ 10:43 PM

    • Assigned user set to “Andrew Dupont”
  • Nick Stakenburg

    Nick Stakenburg October 4th, 2008 @ 03:15 AM

    Andrew, what is your priority then? I would implement the Event#observe approach into core for performance reasons. With 1.6.1 people could easily implement this using custom events themselves.

    If this was provided using custom events you'll start to see tickets about why this wasn't implement differently for performance. Imo, Core should provide the implementation with the best performance instead of going with the custom event approach for the sake of using custom events. Maybe you'll prove me wrong with the custom events, guess we'll have to see how it'll perform.

    I know you've mentioned several times that this was possible using custom event, but why use them? Just because it'll become possible in 1.6.1? If you understand my argument about custom events not being the best approach, why even bother?

  • Andrew Dupont

    Andrew Dupont October 5th, 2008 @ 12:10 AM

    Nick, we're planning to throw a bunch of useful custom events into 1.6.1, mouse:enter and mouse:leave being among them. I am very, very hesitant to special-case two events inside of Event.observe when we have an facility for custom events.

    It's not a "slippery slope" issue; it's a matter of doing the least surprising thing. The system we've created is one in which custom events go through our own special system, but other events get passed straight to the browser, and if we break that convention I think it'll be confusing to users.

    Again: I promise I'll recosider my approach if it turns out not to be performant. When I said I understood your argument, I meant that I see both sides of this, not that I think my way is wrong but I'm going ahead with it nonetheless.

  • Phunky

    Phunky December 1st, 2008 @ 06:08 PM

    • Assigned user cleared.

    Is there any update on this functionality being added or even an example for how to implement mouse:enter/leave?

  • Andrew Dupont

    Andrew Dupont December 2nd, 2008 @ 01:21 AM

    • Assigned user set to “Andrew Dupont”

    As the ticket says, it's planned for 1.6.1. We'd like to release this version sometime in January.

    If you need it before then, you can use Nick's patch; right now there's no way to do non-bubbling custom events, so you can't do mouse:enter and mouse:leave.

  • Diego Perini

    Diego Perini December 2nd, 2008 @ 02:58 AM

    I have always wanted to ask what is the explicit and expected behavior (documented or not) to people really using it in their projects and/or writing core code for it.

    Are "mouseenter" or "mouseleave" meant to reflect the document source position of the elements (contained or not) or are/were they meant to reflect the viewport position and the device hovering them ?

    Thank you for your observations,

    -- Diego

  • GitHub Robot

    GitHub Robot February 28th, 2009 @ 05:07 PM

    • State changed from “enhancement” to “resolved”

    (from [9d7a981e4c434ee7ca5a1219ab5a150552c411d1]) Add first-class support for mouseenter and mouseleave events in non-IE browsers (IE supports them natively). [#350 state:resolved] (Nick Stakenburg, Andrew Dupont) http://github.com/sstephenson/pr...

  • Tobie Langel

    Tobie Langel July 24th, 2009 @ 03:39 AM

    • Tag changed from discuss, events to events, needs:discussion

    [not-tagged:"discuss" tagged:"needs:discussion" bulk edit command]

  • Tobie Langel

    Tobie Langel July 24th, 2009 @ 03:55 AM

    • Tag changed from events, needs:discussion to needs:discussion, section:dom

    [not-tagged:"events" tagged:"section:dom" bulk edit command]

  • Tobie Langel

    Tobie Langel July 24th, 2009 @ 03:56 AM

    [not-tagged:"events" tagged:"section:dom" bulk edit command]

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

The Prototype JavaScript library.

Shared Ticket Bins

Attachments

Referenced by

Pages