W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2013

Re: Better event listeners

From: Glenn Maynard <glenn@zewt.org>
Date: Mon, 11 Feb 2013 18:31:19 -0600
Message-ID: <CABirCh_svF0=dUNXMJ-=moEWJCNB-7m=ek-v4WFbNp+wKiO6_w@mail.gmail.com>
To: www-dom@w3.org
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
Received on Tuesday, 12 February 2013 00:31:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:20 UTC