[Bug 16491] Add simpler and better event registration system

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

--- Comment #15 from Glenn Maynard <glenn@zewt.org> ---
(In reply to comment #14)
> 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.

It's not inconsistent.  The overwhelming majority of listeners don't want to
receive the event during the capturing phase, and almost zero listeners want to
receive events during both.  It's a distinction that almost every event
listener cares about, so much so that we usually don't want to have to think
about it at all.  The other criteria are all vanishingly rare by comparison.

That doesn't mean that no other filters are useful to have at an API level, but
I disagree with the argument that the existance of the capture criteria implies
we should necessarily avoid the need for "if(e.something) return" checks in
less ubiquitous cases.

> 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.

I'm not saying we should have no filters.  I do think we should have a tighter
criteria than "somebody, somewhere might want to filter on this", though.  So,
I don't think being able to specify a set of event phases (["capture",
"target"]) (for example) is worthwhile.  My intuition, at least, is that
filtering on isTrusted is also not worth it, at least for now.

I don't think we're fundamentally disagreeing.  I just think we should be
conservative in adding API-level filters until we know that they're worthwhile,
especially since this API is already proposing a pretty big bulk of new
features.

> 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.

I hadn't thought of that, and it's interesting: it means delegated listeners
can be effectively equivalent to listeners on the event itself, while having
the benfits of delegation.  It would add some complexity to the basic event
dispatch model and I'm not sure how to polyfill it, so we should think about
this carefully, but at first glance I like it.

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

Received on Saturday, 16 February 2013 06:07:51 UTC