Re: addEventListener naming

On Sat, Sep 12, 2009 at 2:21 PM, Jonas Sicking <> wrote:
> On Sat, Sep 12, 2009 at 1:19 PM, Doug Schepers <> 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

> 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


Received on Sunday, 13 September 2009 02:06:38 UTC