Re: Better event listeners

On 5/01/13 11: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, 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.
>
>

Some use cases - mostly related to event-delegation:

1. pushState assisted navigation
This might require handling click events on all hyperlinks <a 
href="..."> in the page.
Instead of attaching handlers to all <a href> in the page - most of 
which will never be clicked - I would like to register one handler on 
the document and use event-delegation.

A hyperlink might contain other elements meaning that the <a> is never 
the `target` of the click. e.g.
     <a href="/index.html"><span>Home</span></a>

Additionally, browsers have different behaviors for clicks that aren't 
generated by the left button, or clicks that occur while a modifier key 
(metaKey, ctrlKey, altKey) is depressed. I don't want to handle a click 
in those cases.
I'd like my handler to only be called for an event matching:

     {
         type: 'click',
         element: 'a[href]',
         eventPhase: "bubbling",
         button: 'left',
         metaKey: false,
         ctrlKey: false,
         altKey: false,
         shiftKey: false
     }

I don't want my handler called until the event bubbles up to the 
document - this will allow other handlers to prevent my handler if 
appropriate. Naturally I want to know which element matched the selector.

Alternatively, if the handler is triggered as the event bubbles thru the 
<a href>, I would extend the event object with fields like

     {
         url: event.currentTarget.href,
         replace: false,
         hyperlink: event.currentTarget
     }

Another handler on the document would take care of pushState (if the 
event hasn't been stopped or prevented).


2. Sortable table
This might involve handling all click events on <th> that are inside the 
<thead> of the table.
Again, the <th> could easily contain other elements which mean it is not 
the `target` of the event.
I would prefer my handler to be called as the event bubbles through the 
<th>. My handler could be prevented by a capturing event handler.
I'd like my handler to only be called for click events on descendants of 
the <table> that match

     {
         type: 'click',
         element: 'thead th',
         eventPhase: "bubbling",
         button: 'left',
         metaKey: false,
         ctrlKey: false,
         altKey: false,
         shiftKey: false
     }


3. Tree
A tree could be a base pattern for a directory, document-map, emulated 
<select>.
The tree might be collapsible or sub-lists might only appear on 
mouseenter. It might have dynamically generated or AJAX'd content.
It is implemented as a list of lists, perhaps like this:

     <div class="tree">
         <label>My Tree</label>
         <ul>
             <li>1
                 <ul>
                     <li>1.1</li>
                     <li>1.2</li>
                     ...
                 </ul>
             </li>
             <li>2
                 <ul>
                     <li>2.1</li>
                     ...
                 </ul>
             </li>
             ...
         </ul>
     </div>

I want to detect UI events on any <li> in the tree, but I don't want to 
add listeners up front because some items might not be present, and 
especially since most of them won't ever be interacted with.

The tree might have an *active* item, which can be set by a cick. My 
click handler should only be called for descendants of the <div 
class="tree"> that match

     {
         type: 'click',
         element: 'li',
         eventPhase: "bubbling",
         button: 'left',
         metaKey: false,
         ctrlKey: false,
         altKey: false,
         shiftKey: false
     }

I need my handler to be called as the event bubbles through <li> so that 
I can prevent ancestor <li>'s from also handling it.


Apologies for the verbosity.  I'll add some analysis in another email.
Sean

Received on Monday, 18 February 2013 03:23:27 UTC