- From: Alex Russell <slightlyoff@google.com>
- Date: Fri, 24 Apr 2009 14:09:29 -0700
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 > >
Received on Friday, 24 April 2009 14:09:29 UTC