[whatwg] Exposing EventTarget to JavaScript

[Ojan Vafai]

On Fri, Apr 24, 2009 at 6:37 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> Ojan Vafai wrote:
>
>> What would be a better approach?
>>
>
> I believe Alex proposed some in this thread as aliases for
> addEventListener.  Those looked a lot better to me, for what it's worth.


I have no problem with adding these aliases as long as the DOM and JS APIs
match. I agree that listen/unlisten are better names.

If a linear list of things the event is targeting is sufficient, of course,
> and we're ok with the random third argument of addEventListener being carted
> around, then we might be ok using it...


I think this is sufficient. Although it is a bit unfortunate that dispatch
order is undefined. It would be great if we could just agree that dispatch
order is the order the handlers were registered in. I don't know the
technical details here though. Is there a reason that they can't dispatch in
a guaranteed order?

>From my point of view, in addition to the things already mentioned, an issue
> with addEventListener is that removing requires a match of both the listener
> and the bubbles arg.  So for example:
>
>  node.addEventListener("foo", function() { ... }, false);
>
> if I want to remove it later, I suddenly have to pull the function out and
> give it a name.  And then on the remove end duplicate the "foo" and false.
> Maybe it's just me, but I'd have much preferred something like:
>
>  var token = node.addEventListener("foo", function() { ... });
>
>  // later on
>  node.removeEventListener(token);
>

Yes, I completely agree that this is a significant shortcoming of
addEventListener. It seems like we could safely add this to the current API.

In short, I'm happy with evolving addEventListener to make it suck less if
we can keep the JS and DOM APIs consistent.

Ojan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090424/815ae0ad/attachment-0002.htm>