W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2013

Re: Better event listeners

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Tue, 08 Jan 2013 14:16:10 +0200
Message-ID: <50EC0E0A.4000906@helsinki.fi>
To: Glenn Maynard <glenn@zewt.org>
CC: Anne van Kesteren <annevk@annevk.nl>, www-dom@w3.org, Yehuda Katz <wycats@gmail.com>
On 01/08/2013 03:02 AM, Glenn Maynard wrote:
> On Sun, Jan 6, 2013 at 7:01 AM, Olli Pettay <Olli.Pettay@helsinki.fi <mailto:Olli.Pettay@helsinki.fi>> wrote:
>
>     Really? How would it work in a sane way with mouseenter/leave which behavior
>     is largely about non-bubbling.
>
>
> I'm not sure I understand the question.  For event delegation, you want mouseenter to bubble, just like any other event.


If you handle mouseenter/leave in bubble phase, you're pretty much forced to check the target.
But sure, based on your comment below these new kinds of listeners which get all the events, target checking
would need to happen most cases anyway


>
> Note that event not bubbling is only a convenience.  It's trivial to get the same effect in an event listener without it: if(e.eventPhase !=
> Event.AT_TARGET) return;
>
>     Or perhaps you don't meant normal bubbling but you mean that if there is
>     this kind of special event listener in an ancestor, such listener should be
>     called even is the event doesn't bubble.
>
>
> Firing event listeners on ancestors, after calling it on the target, is exactly what bubbling is.
>
> All this would mean (regardless of whether via an addEventListener flag, as I suggested, or implicitly with another method, as Anne suggested), is
> that all events would bubble, but event listeners would only be fired during the bubble phase if either 1: the event's bubbles flag is set, or 2: the
> event listener's always-bubbles flag is set.  The result would be identical for existing code (as it needs to be, of course), since listeners with the
> current APIs would always have their always-bubbles flags unset.
>
>
> On Sun, Jan 6, 2013 at 7:02 AM, Olli Pettay <Olli.Pettay@helsinki.fi <mailto:Olli.Pettay@helsinki.fi>> wrote:
>
>     Or just use capturing event listeners.
>
>
> I think this can only be recommended as a solution if it's correct to *always* use capture for the delegation pattern.  If you need to carefully use
> capture for some cases and not for others, for the same basic pattern, it'd be better to solve the bubbles flag problem itself.
>
> (I don't feel too strongly about this, but if we're going to do it at all, I think extending addEventListener to take a dictionary and make this an
> option is better than adding a new entry point with subtly-different behavior.  It's too subtle a difference, so it'll probably confuse and bite people.)
>
>
> On Mon, Jan 7, 2013 at 11:12 AM, Benoit Marchant <marchant@mac.com <mailto:marchant@mac.com>> wrote:
>
>     - How about a better way when your handlers are objects and not functions? The big problem with functions is removing the listeners, it has to be
>     the same function object and there are countless leaks today of people not realizing that their removeEventListener, when they thought of doing it
>     actually doesn't do anything.
>
>
> Using objects instead of functions is a pattern inherited from Java, which is unnatural and unneeded in JavaScript.  Callbacks should simply be functions.
>
> As I mentioned earlier, it *seems* like it would be straightforward to add handler objects to addEventListener, eg:
>
> this.click_handler = elem.addEventListener("click", function(e) { });
> this.click_handler.stop();
>
> which would be equivalent to the corresponding removeEventListener call.  (I don't feel that strongly about this, either, since the patterns I'm using
> for removing listeners work quite well already, but maybe it'd be helpful for others, and we don't seem to need a new "on()" API to accomplish it.)
>
>     - Perfornance. Event Delegation as a concept has been pushed because it's slow to install all these listeners upfront. Is that being worked on?
>
>
> It'll always be slower to install a thousand separate listeners than to install a delegate listener once.
>
> Delegation also makes installing dynamic content using innerHTML much simpler, since you don't need to dig into the result to find the DOM nodes to
> attach listeners to.
>
> --
> Glenn Maynard
>
Received on Tuesday, 8 January 2013 12:16:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2013 12:16:49 GMT