- From: Marcos Caceres <w3c@marcosc.com>
- Date: Sat, 5 Jan 2013 13:59:01 +0000
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: www-dom@w3.org, Yehuda Katz <wycats@gmail.com>
On Saturday, 5 January 2013 at 12:26, Anne van Kesteren wrote: > We discussed this a long time ago. One thread (don't know if there were others): http://lists.w3.org/Archives/Public/www-dom/2012JanMar/0102.html > 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. agree. > Selector-based filtering of > event.currentTarget should be there, but optional. agree. > I'm not sure about > the data feature, Yehuda? This is very useful as only custom events provides "details". Sometimes you need more context (i.e., data) than just what is provided by DOM Event or any UI events that are layered on top. > 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. That would be nice (though this might need to happen at a higher level). Trying to resist thinking about what the API might look like :) > It seems capture-listeners are not needed. At least for now. > I've run into situations where I've needed capture, but I cant' remember the specific situation right now. -- Marcos Caceres http://datadriven.com.au
Received on Saturday, 5 January 2013 13:59:29 UTC