Re: Better event listeners

On 01/05/2013 02:26 PM, Anne van Kesteren 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,
Why (I'm not against it)? Also, how should it work? Should the selector matching run when
event target chain is created or when the event is actually handled.
If the DOM is modified while event is being dispatched, and some parts of the event target chain
isn't anymore in the tree, selector based filtering may cause unexpected results.


  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?
Why?

> 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,
the filtering should be something generic which applies to all the event interface types, even
for those not yet defined.
(Can be tricky to implement and might slow down event handling in certain cases)

> optimization for browsers and speed of the application would be that
> less events need to be processed ideally leading to a better user
> experience.
For things like key events this really doesn't matter much.
For mousemoves and touch events it might.

>
> It seems capture-listeners are not needed. At least for now.
Er, what?





-Olli

Received on Saturday, 5 January 2013 12:53:29 UTC