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

Re: addEventListener naming

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Sat, 12 Sep 2009 19:05:56 -0700
Message-ID: <c9e12660909121905p7becb6c7xe08d7d3d1a3c6490@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Doug Schepers <schepers@w3.org>, "www-dom@w3.org" <www-dom@w3.org>, Alex Russell <slightlyoff@google.com>
On Sat, Sep 12, 2009 at 2:21 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Sat, Sep 12, 2009 at 1:19 PM, Doug Schepers <schepers@w3.org> wrote:
>> Hi, Alex-
>>
>> I've tentatively added the 'listen()' and 'unlisten()' methods as syntactic
>> sugar shorthands for 'addEventListener()' and 'removeEventListener()'.
>>  Obviously, this assumes that the implementers have no objections, and are
>> willing to implement these methods.
>
> For what it's worth, I would rather not implement these new methods in
> Firefox, for the following reasons:
>
> 1. As far as I can tell it has not been shown that the developer
> community at large sees the long name as a significant problem.

It is the first I have heard that complaint.

Regarding long names, I have heard complaint about:
 * document.getElementById
 * document.getComputedStyle(el, "").getPropertyValue(p);

> 2. If the long name is a significant problem, then it can easily be
> worked around in JS by using prototypes. As far as I know no library

I stated in another thread that modifying host object prototypes is
not cross browser and doesn't work cross-frame. It is also not
standard. The practice has been the source of problems in Prototype.js
but that hasn't stopped Mootools developers from making the same
mistake.

> does this, further indicating that this isn't something that
> developers find to be a bug burden. (In fact, if we should 'rename'
> any method, it would be to rename 'document.getElementById' to '$').

You can't be serious.

Do you have any idea how many sites that would break?

> 3. There's a better suggestion in this thread for how to get rid of
> the extra argument; simply mark it [optional].

How would a program determine if the extra argument were optional or
not? And if it could, it is still pointless. Consider:-

if(isUseCaptureOptional()) {
  node.addEventListener("click", cb);
} else {
  node.addEventListener("click", cb, false);
}

I hope you can see the humor in that.

If Events is to be redesigned, then specific problems need to be
drawn. I have identified two so far and mentioned them in another
thread. Again, they are:-

1) No good way to determine if an object /generates/ an event.
2) Creating and dispatching events is painful and the API is not
easily extensible.

I've addressed those as proposals that fit my criteria for new proposals:
 1) feature detectible
 2) a fallback strategy can be provided

Garrett
Received on Sunday, 13 September 2009 02:06:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:03 GMT