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

Re: addEventListener naming

From: Alex Russell <slightlyoff@google.com>
Date: Thu, 27 Aug 2009 07:10:22 -0700
Message-ID: <6fc58d0d0908270710nf7eed01q70a2bc299b64f7c@mail.gmail.com>
To: Sergey Ilinsky <castonet@yahoo.co.uk>
Cc: www-dom@w3.org, Doug Schepers <schepers@w3.org>
On Thu, Aug 27, 2009 at 3:19 AM, Sergey Ilinsky<castonet@yahoo.co.uk> wrote:
> 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 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);
> })

I do it often enough that it sucks to need to do by hand.

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

I'm trying to do what every JavaScript library worth its salt ALREADY
does, which is to remove the crazy impedance mismatch between DOM and
JS. DOM events are already "high level"...but so is AOP notification
in JS, and it's not like I'm suggesting that these events be plumbed
from deep in the server...this is code that's already servicing the
UI. It gets particularly egregious when you consider that there's not
way to generate NEW event types in the DOM, rendering it not only
alien, but also hostile. No wonder JS library authors spend so much
time trying to forget about DOM events.

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

Event generation via, say, somenode.click(), has been part of the DOM
for at least a decade. You may not like it, but that doesn't mean it's
going away, and if it's going to stay, we should make it not suck.

Received on Thursday, 27 August 2009 14:11:03 UTC

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