W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: addEventListener naming

From: Doug Schepers <schepers@w3.org>
Date: Fri, 24 Apr 2009 18:23:59 -0400
Message-ID: <49F23BFF.3000104@w3.org>
To: Alex Russell <slightlyoff@google.com>
CC: public-webapps@w3.org
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.

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:

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

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)

3) what would we do for older browsers that don't understand the new 
method?  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." ^_^ )

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

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
Received on Friday, 24 April 2009 22:24:10 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT