On Jun 12, 5:46 am, Nick Stakenburg <[EMAIL PROTECTED]> wrote:
> I've been saying this for some time but custom events seem to be used
> as an excuse not to implement this properly, like other frameworks
> have done. Of course it can be done with custom events but it's
> clearly not the best approach. Ah well, I guess this needs more time
> before others draw the same conclusion.

Nick, I have no opinion on whether or not mouseenter/mouseleave should
be rolled into core, but if they are I think they should be
implemented as custom events, just like we implemented dom:loaded. I'm
highly reluctant to give the former a special treatment that we didn't
give the latter.

As we discussed on GitHub, the solution is to enhance Element#fire so
that one can tell a custom event not to bubble. In most browsers this
is easy. In IE, as you noted, the fireEvent method gives no control
over bubbling behavior. But IE also implements a bunch of proprietary
events that nobody ever uses, and some of these are *by their nature*

For instance, there's "onpropertychange," which is IE-only and not
part of any standard [1]. Just like we borrow "ondataavailable" for
custom events, so can we borrow "onpropertychange" to get non-bubbling
custom events. Some quick code confirms this works. I've set this as a
to-do for 1.6.1.

Fun fact: originally I'd wanted to use the "onbounce" event [2], which
is one of three different events that IE reserves for MARQUEE
elements. It does not bubble, but is cancelable, so it would've been
_perfect_. Sadly, IE throws an error when you try to trigger an
"onbounce" event on a non-MARQUEE element. I promise I'm not making
this up.

You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 

Reply via email to