W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2011

Re: EventTarget.on

From: Glenn Maynard <glenn@zewt.org>
Date: Wed, 23 Nov 2011 12:43:10 -0500
Message-ID: <CABirCh-1ybbeyV9Sak+AYHcQ=b7OGFcmv32KEgtbzq5MF2nuEg@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: Jake Verbaten <raynos2@gmail.com>, www-dom@w3.org
On Wed, Nov 23, 2011 at 12:07 PM, Jake Verbaten <raynos2@gmail.com> wrote:

> Adding a redundant method that clashes with what everyone already
>> associates with the name (event delegation),
>>
>
> In prototype and jQuery el.on(ev, handler) works and is an alias for
> adding an event listener.
>

But it also adds event delegation.  I'd also (more importantly) predict
headaches due to the Prototype name clash; new code using on() couldn't be
used on sites that load Prototype.  It's easy (and correct) enough to blame
Prototype for patching methods into the API like that, but the problem
would still be there.

Anyhow, all that's needed is to pick a different word (if a new method is
needed at all).

On Wed, Nov 23, 2011 at 12:12 PM, Anne van Kesteren <annevk@opera.com>wrote:

> On Wed, 23 Nov 2011 18:07:18 +0100, Jake Verbaten <raynos2@gmail.com>
> wrote:
>
>> Would it be worthwhile to have some kind of event delegation mechanism?
>>
>
> I think so. Is there no need to unregister these handlers?
>

All handlers should be removable.

Prototype allows removing these handlers by returning an object with a
"stop()" method.  Prototype's API has its quirks, but I do like this a
*lot* better than removeEventListener, because with removeEventListener I
can't use anonymous functions.  This allows:

this.clickHandler = this.container.on("click", function(e) {
e.preventDefault(); });

Later, this.clickHandler.stop() is called to remove it.  I can also
accumulate an array of handlers, and call stop() on all of them to remove
all listeners.


> At TPAC something like was discussed:
>
>  target.on.eventName.add(**callback, optional options)
>  target.on.eventName.remove(**callback)
>
> options could be used for delegation, only firing when AT_TARGET, only
> during BUBBLING_PHASE, etc.


That's cute, though I'd suggest adding new features to addEventListener
directly, and anything like this would just a thin syntax sugar wrapper on
top of addEventListener.  Do you know of legacy restraints that would
prevent overloading addEventListener for (type, listener, options)?  (The
"optional boolean capture" would need to be split into a "boolean capture"
version and a two-argument version, of course.)

-- 
Glenn Maynard
Received on Wednesday, 23 November 2011 17:43:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:08 GMT