[whatwg] Exposing EventTarget to JavaScript

[Alex Russell]

On Fri, Apr 24, 2009 at 1:29 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Apr 24, 2009, at 11:29 AM, Aaron Boodman wrote:
>
>> I like the basic idea, but I think drawing too much inspiration from
>> DOM events is a bad idea. What does it mean to "capture" a pure JS
>> event?
>
> There's really two aspects to the DOM event model. One is the basic
> addEventListner / dispatchEvent mechanism, which allows objects to have
> event listeners attached.

Something missing from this (and from Erik's original mail) is the
ability to enumerate listeners. A facility for this should probably be
added.

> The other is the bubble/capture event flow in the
> DOM tree. It can make sense for an object to be an EventTarget without
> participating in bubble/capture, because it is not part of the DOM document
> tree. An example of this is XMLHttpRequest.

Even in the XHR case, adding more than one listener is currently a
pain. Part of the goal here would be to make event dispatch across
lists of listeners as natural in JS as it is in DOM.

Regards

>> Further, the DOM event model has problems. It would be nice if
>> events were first-class, not strings. It would be more idiomatic JS, I
>> would argue, to do someObject.onClick.add(<handler>).
>
> It's a bit late in the game to change the DOM itself to work that way. And
> having some other event mechanism that works like this, while DOM events
> continue to work as they do, would be confusing I think. One advantage to
> string event names is that users of the DOM can invent custom event names at
> will. In addition, it is possible to register for events that are not
> supported without having to do feature testing. There are certainly
> downsides to the design but it is not without precedent.
>
> Regards,
> Maciej
>
>