[Bug 16491] Add simpler and better event registration system

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16491

--- Comment #14 from Jonas Sicking <jonas@sicking.cc> ---
(In reply to comment #13)
> The distinction between bubbling and capturing listeners is useful, since
> otherwise you'd be firing every single even handler up the DOM tree twice.

So? If one of the calls always returns immediately then it still behaves
correctly.

I do agree that the distinction is useful, my point is that your argument is
inconsistent. We shouldn't allow filtering such that the listener is only
notified at the target since that can easily be implemented using logic in the
listener.

On the other hand you are saying that we should allow filtering based on
capturing vs. bubbling phase as to avoid starting the handler unnecessarily.

> But we don't need to try to eliminate every possible condition you might
> short-circuit your event listener with.  Maybe somebody would want to do
> something weird like "if(e.eventPhase != e.AT_TARGET)", but they should use
> script for that.  The same applies to checking e.isTrusted, or shiftKey, or
> countless other possible filters.

I agree that we can't create every possible filter that people will want to do.
But we also shouldn't have no filters as per your own argument above.

The trick is to find which filters are common enough that people will want to
filter on them.

FWIW, I think that if we support an "at target" phase, then we can remove the
"normalBubbles" flag.

> No, delegation is more than that.  You want to know if any node between
> yourself (the delegate) and the target matches the selector.  That is, given
> 
> <div class=delegate>
>     <div class=box>
>         <span>hello</span>
>     </div>
> </div>
> 
> If you put a listener on .delegate to listen to clicks on .box, it should
> still fire if you click within the span, even though the target itself
> doesn't match the selector.  In other words, starting at the target, search
> up through parent nodes to find the first one that matches the selector. 
> (This is http://api.jquery.com/closest.)
> 
> Also, you'll want to know what element actually matched the selector. 
> jQuery sets currentTarget to the matched element, and sets an additional
> property delegateTarget which is the original currentTarget (the element the
> event listener is bound to).

This is quite interesting! This makes a lot of sense. I wonder if we should
even make the firing order such that the listener fires along with listeners
registered on the .box.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Saturday, 16 February 2013 05:43:15 UTC