savetheclocktower's javascript-stuff Feed  

I figured out how to do it, actually. I’ll follow up on the mailing list.

Element#fire can’t fire non-bubbling events, at least not on IE since fireEvent will always fire bubbling events.
http://msdn.microsoft.com/en-us/library/ms536423(VS.85).aspx

You guys are right that these events shouldn’t bubble. Right now anyone writing a handler for a mouse:enter event would have to look at the event’s "target" property to be sure it’s coming from the element itself, rather than from one of the element’s child nodes.
This doesn’t make this script useless, in my opinion, but it’s certainly a surprising behavior and something that ought to be fixed. I think a future version of Element#fire should stipulate whether the event should bubble.

staaky is right about this experiment. This implementation is beautiful but kinda useless.
native IE implement of mouse(enter|leave) does not bubble, that’s their purpose, that’s what make them so useful for real use case (= hover observation without worring about false positive children hover observation). This way the element represent the target zone to be entered / left (which is 99% of mouseover/out usecase IMHO).
So by definition native implementation of mouse(enter|leave) CANNOT be delagated. The only purpose is direct element observation.
So what is the purpose of those mouse:enter / mouse:leave:
- it is not direct observation, as it has exactly the same issue, custom event bubbles, so children element of an observed element will trigger the event when they are entered (even if the cursor already entered the observed element).
So that you’ll have to filter out whether the event comes from a child element OR an external element. Exactly the same issue than mouseover in non IE browser.
- is it event delegation ? no because it won’t work either
The problem in delegation of mouseEnter/Leave is not whether :
relatedTarget.descendantOf(event.target())
the problem is that :
relatedTarget.descendantOf(delegated_element)
so it won’t be of any help (moreover I guess that in IE it won’t even trigger due to the non bubbling nature of mouseEnter but I have not tested).
Should we need an emulation of mouseEnter|Leave in prototype ?
Why not, but it’s only purpose will be direct element observation (not delegation) due to its non bubbling nature. Its could be simple if it wrap the real handler in non IE browser and relies on event.currentTarget instead of event.target to trigger the handler. The complicated part is for stopping observation.
Anyway there can’t be any delegation friendly mouseEnter/mouseLeave implementation outsite a delegation stack. It will have to be build in with the delegation stack because you will need to have access to the delegated event. So a multi purpose solution like this one just can’t work on it’s own, and that’s a pity.

Yep, this can be nice for event delegation purposes.
I’d prefer to implement this like jQuery and Mootools have done it. Along the lines of $(element).observe(‘mouseleave’, handler). Following the spec in making sure these events don’t bubble, for the reasons I’ve mentioned.
From all the discusion I’ve read on this it sounds like custom events are used as an excuse not to do the same. Comparing pros and cons just doesn’t want to make me jump on the custom event bandwagon for this one.

To each his own I suppose :)
I will say that the advantage of event delegation is that you only need one observer to handle behavior for a ton of elements. Having observers on a ton of elements can get expensive in terms of performance. Event delegation solves this.
Also, when adding content to a page dynamically, event delegation obviates the need for re-assigning my behaviors.
See this blog post: http://devthatweb.com/view/basic-event-delegation-in-prototype if you’re interested in that approach (though ignore my implementation of event delegation. It’s hideous).

That won’t make this easier to use. By wrapping Element#observe you can just do $(element).observe(‘mouseleave’, handler) and have it work as expected on all browsers without the overhead.
Nothing wrong with custom events, it’s just not the right solution for this issue imo.

You can observe mouse:enter and mouse:leave at a parent level, then check to see if the target element of the event matches the type of element that should receive a certain behavior and deal with it there.

My point is, mouseenter and mouseleave should not bubble. The custom events will reach all ancestor elements because of bubbling. This makes it impossible to observe an element for mouseenter/leave because events from child elements render this useless. These events are not substitutes for real mouseenter mouseleave events, since those don’t bubble.
I can imagine a possible fix for non-IE browsers. Since it’s not possible to fire non-bubbling events in IE that brings me to the conclusion that the only proper way to implement this is by wrapping it into core. It’s not that big a change, even less code then this addon.

Well, I just can’t win with these typos.

(I coulud see the code base getting out of hand that is)

@staaky, Allowing mouse enter/leave to bubble makes them eligible for event delegation, which is a big win. I like how Prototype’s core, for the most part, gives you tools to implement things like this. I could the codebase getting out of hand really quickly if it were to try to encompass special behaviors like this.

I don’t see how this would be of any use. Custom events bubble up, the power of mouse enter/leave is that they don’t bubble.
I remember that you’ve been trying to convince me with your blog post that implementing this with custom events was the right way to go. I still think it would be better to just wrap this into core, especially after seeing this implementation. That would leave IE untouched and doesn’t fire events all the time.

I really like the idea, it’s very useful with event delegation.
I’m actually using it, thanks!

@madrobby: When I said "untested" in the commit message, that means I haven’t even plugged this into a page to see if it works. And aren’t you the guy who’s using events for every single heartbeat in scripty2? ;-)
@kangax: Yeah, it’s a whole thicket of ick. I intentionally stayed away from keys that have associated charCodes (keys that produce characters on screen). I consulted QuirksMode a bit as I was writing this, but — again — I have not tested it. Let’s talk about this in Campfire.

I remember I had problems with certain keys not working with "keydown" and others not working with "keyup" – http://github.com/kangax/protolicious/tree/master/key_observer.js
Maybe we could combine both into one awesome plugin : )

That’s pretty sweet. Anything to say about performance? Wondering about overusing events, especially on the iPhone.