Re: addEventListener naming

Wow, I just found this thread again. I suck for having not replied
earlier. Sorry 'bout that. Comments inline.

On Fri, Apr 24, 2009 at 3:23 PM, Doug Schepers<schepers@w3.org> wrote:
> Hi, Alex-
>
> Alex Russell wrote (on 4/24/09 5:31 PM):
>>
>> The DOM function "addEventListener" is probably too long. It should,
>> instead, be named something much shorter owing to the amount of
>> exercise it receives. Further, it should default the last parameter to
>> be "false" (non-capture-phase). This call:
>>
>>     node.addEventListener("click", function(e) { /* ... */ }, false);
>>
>> Should be able to be written as (e.g.):
>>
>>     node.listen("click", function(e) { /* ... */ });
>>
>> Similarly, "removeEventListener" should be aliased as "unlisten". As a
>> further help, the common-case operation of listening-for-a-single-call
>> is currently written as:
>>
>>     var h = function(e) {
>>         /* .... */
>>         node.removeEventListener(h);
>>     };
>>     node.addEventListener("click", h);
>>
>> And given how common this operation it, it should probably have an alias:
>>
>>     node.listenOnce("click", function(e) { /* ... */ });
>
> Obviously, we can't get rid of "addEventListener" or "removeEventListener".
>  In the past, we've had pushback from browser vendors that event aliasing is
> frowned upon.

you mean "onclick" -> "click"? Or when you say "event aliasing" are
you referring to listenOnce vs listen? listenOnce() is just an
automation of a common idiom that's not currently supported in the
API, not alias.

> Personally, I'm fine with your suggestion, and I'd be fine with putting it
> into DOM3 Events on the EventTarget interface.  Here are some of the
> challenges that would need to be overcome:

The bigger challenge will be in getting the ES WG to accept a native
listen() method for all JavaScript objects. Having a listen() method
in the DOM is only half of the solution: getting to an integrated
development environment means that we should also be able to expose
the exact same API for methods on regular JS objects.

> 1) browser implementers would have to sign off on it, and commit to putting
> it into browsers

That's just a constant for any new proposal. Preferably, the DOM WG
shouldn't pick this up until there's at least one implementation,
right?

> 2) "event aliasing" would need to be better defined (maybe... if we
> introduced it simply as a new method, and don't dig into the rathole about
> what "event aliasing" is, that would be fine with me)

Again, I'm not sure which this refers to...

> 3) what would we do for older browsers that don't understand the new method?

They're screwed anyway. Progress should not be held up by old browsers.

>  Script libs are great, but only take us so far... if people have to use a
> script lib to use "listen()", then why change it in the first place, when it
> can be aliased in the script lib anyway?  (I'm not arguing against it, just
> raising the issue... maybe the answer is: "Make people upgrade their
> browsers to use new technology." ^_^ )

Just to take this argument to it's logical conclusion, why should we
bother with anything new in the DOM since everyone already uses JS
libraries to avoid the DOM at all costs anyway? The JS libraries
should just fix everything.

*gulp*

> I like your idea of "listenOnce()".  Would that also be removed by
> "unlisten()" in case the author wanted to cancel it, or would it require its
> own remover?

Whichever comes first = )

>  Is it worth thinking about simply adding an optional parameter
> to el.listen( "evtname", function(e) {}, number-of-times-to-listen )?
>  (Probably not.)  Listing some use cases for it might help this along.

It'd be nice of a listen() could take optional positional params to
treat as partial applications, but that's sort of a higher-order
discussion to have about how to pack arguments (i.e., if we peel back
the format of Event objects, could you coerce arguments into Event
objects?).

Regards

Received on Wednesday, 26 August 2009 23:25:40 UTC