Re: addEventListener naming

Hi, Alex-

Thanks for the reply.

The DOM3 Events work is now going to the mailing list www-dom@w3.org, so 
I am CCing that list.  Same group (WebApps WG), just a different list so 
I can better concentrate.

Ignore everything I said about event aliasing... I don't know what I was 
thinking, this is a method, not an event type... I was probably tired or 
rushed at the time.

Replies inline...

Alex Russell wrote (on 8/26/09 7:24 PM):
> 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".
...
>
>>  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.

By "ES WG", I take it you mean TC39?  This would be a DOM method; I 
don't think there is any particular coordination needed with ECMA on 
this (unless I'm missing something).  This would not be on all JS 
objects, right, just EventTargets?


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

Yup.  So, implementers... what do you think?


>Preferably, the DOM WG
> shouldn't pick this up until there's at least one implementation,
> right?

Not necessarily.  If we do decide put it in DOM3 Events, it would be 
with the agreement of implementers who have already committed to 
implementing it, so it's just another method to implement.

(BTW, there is no DOM WG anymore... the WebApps WG is maintaining and 
building on the DOM specs.)


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

I wasn't arguing against adding the feature... I'm asking "how do we 
solve the problem of older browsers?"  I can see a comprehensive script 
lib being useful for a whole range of DOM3 Events stuff.  The active 
participants in the DOM3 Events work


>>  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 = )

Okay.


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

Okay.

My chief issue to the general idea of adding "listen()" is that it 
doesn't actually do anything that "addEventListener()" doesn't do.  It's 
nice syntactic sugar, but I would rather add functionality along with 
it, if we are going to do something.  So, take it another step... if we 
were to add a new method for listening to events, what extra 
functionality would it be nice to have?  Can we look to script libs or 
proprietary frameworks for inspiration?  One simple thing might be the 
suggestion above to have the number of times to listen for an optional 
third parameter.  Another one might be the ability to pass string 
parameters that will be passed along to the handler.  Some new 
functionality might justify adding it, and solve other problems than 
just the length of the method name.

We are winding down on new features for DOM3 Events (trying to get it 
out the door), but if there's a lot of implementer enthusiasm on this, 
we could put it in.  Any implementers care to chime in?

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Thursday, 27 August 2009 02:30:12 UTC