Re: [new Feature] QueryEventListeners

Hi Michaël,

On 18/05/2013 12:03 , Michaël Rouges wrote:
> The idea is being able to add events to a collection of nodes, existing
> and future, for a given selector.

This is definitely a useful feature. That said, are you aware of event 
delegation? See for instance:

     http://davidwalsh.name/event-delegate

The most common use that I know of this is jQuery's on() method, which 
can also accept selectors in order to filter nodes:

     http://api.jquery.com/on/

> This would avoid costly solutions like this:
>
> (function () {
>      var catchClickOnAnchors;
>      catchClickOnAnchors = function(event){
>          var anchors, iterator, length;
>          anchors = document.getElementsByTagName('a');
>          for (; iterator < length; iterator += 1) {
>              anchors[iterator].addEventListener('click', function (event) {
>                  console.log('Caught click');
>                  event.preventDefault();
>                  event.returnValue = false;
>                  return false;
>              }, false);
>          }
>      };
>      catchClickOnAnchors();
>      document.addEventListener('DOMSubtreeModified',
> catchClickOnAnchors, false);
> }());

Yes, you *definitely* don't want to do that. For the case you exemplify, 
you can listen for click events on the <body> element, and filter just 
those that are on <a> elements.

You also definitely don't want to be using DOMSubtreeModified. It's slow 
and poorly supported.

It's quite possible that some of the new HTML5 events don't support 
bubbling when they should — and we should triple-check the list — but I 
don't believe that we need a new feature here beyond what we already 
support.

Thanks!

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Tuesday, 21 May 2013 14:28:48 UTC