Re: Better event listeners

On Sat, Jan 5, 2013 at 1:30 PM, Glenn Maynard <glenn@zewt.org> wrote:

> element.addEventListener("click", handler, {
>     // Only fire the handler if event.target matches this selector at
> dispatch time.
>     filter: ".click",
>
>     // If this is a non-capturing listener, fire this event during the
> bubble phase even if the event's bubbles
>     // flag is false.
>     alwaysBubble: true,
>
>     // If true, this is a capturing listener.
>     capture: true,
> });
>
> This allows overriding the annoying bubbles flag, but without it being a
> subtle, implicit difference between APIs.  It does mean event delegation
> takes a little more typing, but it's not bad:
>
> container.addEventListener("focus", handler, { filter: "input",
> alwaysBubble: true });
>
> The "handler = container.addEventListener(); handler.stop();" pattern
> could probably be supported here, too, unless for some reason making
> addEventListener return a value actually has web compat problems.
>

I think this proposal needs more consideration.  It's a simple, consistent
overload of an existing API, instead of a new API.  I've been told that
it's "confusing", but not how or why.  It seems simple and obvious to me,
so I don't know how to address this.  It seems much simpler than having two
distinct event listener APIs.  It doesn't give a nice two-letter function
name, but that's not a reason to have two APIs (at most it simply means
making an alias).

-- 
Glenn Maynard