Re: Better event listeners

On Sun, Feb 17, 2013 at 9:22 PM, Sean Hogan <shogun70@westnet.com.au>wrote:

> It seems capture-listeners are not needed. At least for now.
>>
>
> Some use cases - mostly related to event-delegation:
>

Not to say capture isn't useful, but these mostly aren't actually use cases
for capture, because you shouldn't use capture for these things.  Instead,
you should use normal bubbling listeners.

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

If you mean having links that push script-local state, don't intercept
every <a> press and insert a script that calls pushState.  Just use hashes
and onpopstate; see http://zewt.org/~glenn/hash-navigation.html for an
example.  Intercepting clicks and using pushState is a lot of unnecessary
work, and is a lot harder to make work in general (eg. when users
right-click and select "copy link URL" or "open in new tab", both of which
work perfectly with this example).

That said, if you do want to delegate listeners, you should use bubbling
listeners, not capturing listeners.  For example, that would break <a
href="..." onclick="return false;">, since you'd act on the click before
the anchor's event listener has a chance to cancel it.  One thing the API
we're discussing aims to fix this, by allowing event handlers to ignore the
bubbles flag.


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

Event delegation doesn't depend on the target of the link.  Put a bubbling
event listener on window (or document, or another logical container), and
search up the tree (starting at event.target) for an element matching the
CSS selector "a".  For an example, see
http://zewt.org/~glenn/delegation-example.html.  (Making this simpler is
something this API aims to do.  Element.closest() is also something that
really needs to be added to the selector API, though.)


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

As long as you're listening to onclick (and not eg. onmousedown), you
shouldn't need to do anything special here.

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


This has been suggested recently on
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16491, though it's not yet
clear whether this is a good idea in practice.

-- 
Glenn Maynard