W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2009

Re: addEventListener naming

From: Sergey Ilinsky <castonet@yahoo.co.uk>
Date: Thu, 27 Aug 2009 10:19:09 +0000 (GMT)
Message-ID: <408061.83228.qm@web24403.mail.ird.yahoo.com>
To: Alex Russell <slightlyoff@google.com>
Cc: www-dom@w3.org, Doug Schepers <schepers@w3.org>

> >>>  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 is a great suggestion. WebKit, for example, already defaults the capture parameter.

> >>>>  And given how common this operation it,
> it should probably have an
> >>>> alias:
> >>>>
> >>>>      node.listenOnce("click",
> function(e) { /* ... */ });

I doubt that registering an event listener for a single execution is a common pattern. You might need it in some cases, but definitely not often.
Adding just one line of code, that would unregister event listener, is not a big deal in the rare situations, right?

node.addEventListener("click", function(event) {
    /* */
    this.removeEventListener(event.type, arguments.callee);

> Nope, I'd like to propose that a listen() method be added
> to ALL
> objects in JS. The goal here is to unify JS and DOM
> behavior.
> Hierarchy, bubbling, etc. probably don't apply in the
> non-DOM case,
> but one could image an interface that objects could
> implement (say,
> and eventParent property) to delegate dispatch "up" the
> chain.
> Regardless, it's crazy that we have one way of thinking
> about "events"
> in DOM (a terrible, Java/C++-centric API) and one way of
> thinking
> about events in JS (ad-hoc AOP-style systems and
> monkey-patching).

To my understanding, you are trying to introduce a high-level pattern to a low-level technology, thus merging separated concerns.
What I mean is - the concept of "notifications" is often used in application logic, while such of "events" is used in the GUI.

> Rate-limiting has always been a problem. Also, I didn't
> mention it
> before, but generating events today is just a travesty.
> It's terrible,
> particularly for kbd events. Making it work more like
> function
> dispatch and less like cons-ing up some sort of funky
> implementaiton
> object with opaque params would be a step in the right
> direction.

The browser events (particularly "kbd events") are not supposed to be dispatched by the script author. Moreover, I think this should be even disallowed. 


Received on Thursday, 27 August 2009 10:19:49 UTC

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