[whatwg] Exposing EventTarget to JavaScript

[Alex Russell]

On Fri, Apr 24, 2009 at 10:58 AM, Giovanni Campagna
<scampa.giovanni at gmail.com> wrote:
> 2009/4/24 Alex Russell <slightlyoff at google.com>:
>> On Fri, Apr 24, 2009 at 10:30 AM, Giovanni Campagna
>> <scampa.giovanni at gmail.com> wrote:
>>> 2009/4/24 Erik Arvidsson <erik.arvidsson at gmail.com>:
>>>> Almost all JavaScript libraries and web apps of moderate size end up
>>>> reimplementing events for their UI toolkits or for messaging between
>>>> different parts of their application. To help out with this scenario
>>>> it would be good if an implementation of the EventTarget interface
>>>> could be exposed to JavaScript. This would mean that JavaScript can
>>>> instantiate and extend event targets and dispatch events to these
>>>> objects would work just like it does for DOM elements today.
>>>>
>>>> For example:
>>>>
>>>> var et = new EventTarget;
>>>> ...
>>>> et.addEventListener('foo', fun, false);
>>>> ...
>>>> et.dispatchEvent(eventObject);
>>>>
>>>> would call the handler fun.
>>>>
>>>> The example above actually works today if you replace "new
>>>> EventTarget" with "document.createElement('div')".
>>>
>>> This should not work. This is because the DOM event system (used for
>>> elements) is different from the scripting event system (used for
>>> windows, xmlhttprequest, workers, etc.). The former requires a
>>> document through which the event flows (capture - target - bubble
>>> phases). No document => no event.
>>
>> This is a bug, not a design constraint.
>>
>> JavaScript should be extended to support event dispatch (as Erik
>> outlines) and it should be done in such a way as to cast the DOM event
>> system as an implementation of that dispatch mechanism. Suggesting
>> that JS and DOM shouldn't be more tightly integrated because they
>> havent' been more tightly integrated in the past isn't a legit
>> argument.
>
> DOM = Document Object Model = a set of APIs for representing and
> manipulating documents

That strong distinction between a theoretical OM for some abstract DOM
vs. the actual real-world use cases of "JavaScript is the primary
consumer" has allowed DOM APIs to be mangled beyond usability for far
too long.

> If you need pure scripting interfaces, you can write your own library,
> without reusing EventTarget, that has been used outside its scope with
> debatable results. (what does event.stopPropagation() do for
> XMLHttpRequest events?)

If those events are dispatching down a chain of listeners on some
event, it stops that chain dispatch. The idea that somehow calling a
function in JS and firing an event in the DOM are totally different
thigns that deserve totally different listener APIs is an artifact of
a time when we had much less experience about how these things are
used in the real world. Dispatch is dispatch. Function calls are
events. Treating them differently because they happened to originate
from one part of the platform and not the other is crazy.

>>>> The next and more important step is to allow a JavaScript "class" to
>>>> extend an EventTarget. For example:
>>>>
>>>> function MyClass() {
>>>>  EventTarget.call(this);
>>>>  ...
>>>> }
>>>> MyClass.prototype = new EventTarget; // *[1]
>>>>
>>>> Then addEventListener and dispatchEvent should work as expected on
>>>> MyClass objects.
>>>
>>> This is a matter of host language, not of DOM. In Java, you just do
>>> public class MyClass implements EventTarget {
>>> }
>>>
>>> and the same in ES6 (ES-Harmony)
>>
>> It's safe to fully ignore Java.
>
> Why?
> Moreover, is it safe to fully ignore Python or Perl?

For the purpose of designing DOM APIs for the real world, absolutely.
They are not the "design center". Python has already left the building
(see lxml and the ElementTree API for details on why sane people
abandoned W3C DOM wholesale).

> This is not the
> opinion of the SVGWG, in SVGTiny12.
> And Java bindings are provided by WebIDL and all DOM specifications.

This is a historical artifact which doesn't need to blight the design
of DOM in it's primary use-case. If anything, we should be expressing
Java bindings as a special case, not as the common-case.

Regards