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

Re: Better event listeners

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 13 Mar 2013 08:47:00 -0700
Message-ID: <CA+c2ei9UsRR2TWHLZ+f4pxn8SvjfntTo582Luna=yfDtLCc6Xg@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: www-dom@w3.org, Yehuda Katz <wycats@gmail.com>
On Sat, Jan 5, 2013 at 4:26 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> We discussed this a long time ago. Lets try again. I think ideally we
> introduce something like http://api.jquery.com/on/ Lets not focus on
> the API for now, but on what we want to accomplish.
>
> Type and callback are the basics. Selector-based filtering of
> event.currentTarget should be there, but optional. I'm not sure about
> the data feature, Yehuda?
>
> Should we make all events bubble for the purposes of this new
> registration mechanism? I actually thought Jonas said jQuery did that
> at some point, but the jQuery documentation does not suggest it does.
>
> Should we have event-data-based filtering? E.g. developers could
> register to only get key events for the WASD keys. Optimization for
> developers could be that they get to have one callback per key,
> optimization for browsers and speed of the application would be that
> less events need to be processed ideally leading to a better user
> experience.
>
> It seems capture-listeners are not needed. At least for now.

Something else that occurred to me might be very nice would be able to
get a Future [1] representing the next time a particular event has
fired. I.e. something like

myelement.once("click").then(function(event) { ... });

and

myeleemnt.once("click", { selector: "div > a", phase: "bubble" }).then(...);

The exact syntax here is of course to-be-determined, but the idea is
that it's the exact same syntax as the "on" function, except that it
doesn't take a handler-function argument. Instead a Future is returned
and this future is resolved (using the Event object) the first time
the corresponding "on" handler-function would have been called.

One tricky issue is the exact timing of the call to the .then
function. It would be great if we could enable the resolver function
to do things like call .preventDefault on the event, but that might
require that the .then function is called synchronously which goes
against [1].

[1] https://github.com/slightlyoff/DOMFuture

/ Jonas
Received on Wednesday, 13 March 2013 15:48:03 GMT

This archive was generated by hypermail 2.3.1 : Wednesday, 13 March 2013 15:48:12 GMT