Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 2:41 PM, Alex Russell slightly...@google.com wrote:
On Fri, Apr 24, 2009 at 11:46 AM, Boris Zbarsky bzbar...@mit.edu wrote:
Erik Arvidsson wrote:
To help out with this scenario
it would be good if an implementation of the EventTarget interface
could be exposed to JavaScript.
Why do you want the eventTarget interface as opposed to a sane callback
function registration setup?
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]
So this already works, no?
One more thing needs to be mentioned and that is how event propagation
should work in scenario. If the object has a parentNode property
then the event dispatching mechanism will do the right thing.
What, precisely, is the use case for this in general? In the DOM,
propagating events to parents makes sense (esp. because parents are unique).
What would be the use case in a general object graph?
Most of the JS object graphs that you'll see in the wild either
represent data hierarchies (wherein updates might trigger a UI change)
or wrapped sets of DOM nodes as a way to make up for the fact that you
can't freaking subclass Element from JS. In the latter case, it's
natural to need it to keep up the facade. In the former, it's a
performance convenience.
If I understand you correctly, you want to subclass the Element interface.
If I got that right, then I am not sure how that concept would relate,
as there are not interfaces in javascript, and so I am not sure how an
object that has the interface of Element could also have the interface
of your subclass. In the could have been ES4, maybe, but that is
would-be fiction now.
I can't think of any reason that anyone would even want that, anyway.
In a fictitious version of javascript where interfaces could be
created, you could just create your own, then implement both in the
target class.
But in reality, you could do something retarded like try to subclass
NodeList. Oh yeah, someone already tried that, didn't they?
Garrett
Re: [whatwg] Exposing EventTarget to JavaScript
On Mon, Jun 1, 2009 at 5:53 PM, Garrett Smith dhtmlkitc...@gmail.com wrote:
On Fri, Apr 24, 2009 at 2:41 PM, Alex Russell slightly...@google.com wrote:
On Fri, Apr 24, 2009 at 11:46 AM, Boris Zbarsky bzbar...@mit.edu wrote:
Erik Arvidsson wrote:
To help out with this scenario
it would be good if an implementation of the EventTarget interface
could be exposed to JavaScript.
Why do you want the eventTarget interface as opposed to a sane callback
function registration setup?
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]
So this already works, no?
One more thing needs to be mentioned and that is how event propagation
should work in scenario. If the object has a parentNode property
then the event dispatching mechanism will do the right thing.
What, precisely, is the use case for this in general? In the DOM,
propagating events to parents makes sense (esp. because parents are unique).
What would be the use case in a general object graph?
Most of the JS object graphs that you'll see in the wild either
represent data hierarchies (wherein updates might trigger a UI change)
or wrapped sets of DOM nodes as a way to make up for the fact that you
can't freaking subclass Element from JS. In the latter case, it's
natural to need it to keep up the facade. In the former, it's a
performance convenience.
If I understand you correctly, you want to subclass the Element interface.
Think bigger. I want to create a concrete Element class (that's what a
span is, for all intents and purposes), re-interpret all the other
elements in the DOM class hierarchy in terms of it, and make it
subclassable (or treat it as a Trait for purposes of composition) so
that we can do a component system that lets you introduce new elements
that act sanely both in the HTML and JavaScript senses.
If I got that right, then I am not sure how that concept would relate,
as there are not interfaces in javascript, and so I am not sure how an
object that has the interface of Element could also have the interface
of your subclass. In the could have been ES4, maybe, but that is
would-be fiction now.
I can't think of any reason that anyone would even want that, anyway.
In a fictitious version of javascript where interfaces could be
created, you could just create your own, then implement both in the
target class.
But in reality, you could do something retarded like try to subclass
NodeList. Oh yeah, someone already tried that, didn't they?
...wow. Not sure I should engage with the rest of your message. It's
belligerent for no apparent reason.
Regards
Re: [whatwg] Exposing EventTarget to JavaScript
Alex Russell wrote: Think bigger. I want to create a concrete Element class (that's what a span is, for all intents and purposes) As a minor nit, a span is basically an HTMLElement, not an Element. and make it subclassable (or treat it as a Trait for purposes of composition) so that we can do a component system that lets you introduce new elements that act sanely both in the HTML and JavaScript senses. This has pretty serious security issues of various sorts, depending on what your subclassing would allow you to override. -Boris
Re: [whatwg] Exposing EventTarget to JavaScript
On Mon, Jun 1, 2009 at 6:02 PM, Alex Russell slightly...@google.com wrote: On Mon, Jun 1, 2009 at 5:53 PM, Garrett Smith dhtmlkitc...@gmail.com wrote: On Fri, Apr 24, 2009 at 2:41 PM, Alex Russell slightly...@google.com wrote: On Fri, Apr 24, 2009 at 11:46 AM, Boris Zbarsky bzbar...@mit.edu wrote: Erik Arvidsson wrote: [...] ...wow. Not sure I should engage with the rest of your message. It's belligerent for no apparent reason. The message I am trying to convey -- and let me make this clear -- is that it seems like a really bad idea to even want to try to do that. The subclassing of NodeList has also been attempted before, so one ought to be able to learn from such mistake. I think that makes my intent clearer and disambiguates any disparagement that may have been taken towards persons born with mental retardation[1]. That was not my intent. To those who have relation to such mentally handicapped individuals, my condolences for my careless word choice Garrett
Re: [whatwg] Exposing EventTarget to JavaScript
On Wed, Apr 29, 2009 at 11:39 AM, Alex Russell slightly...@google.com wrote: On Fri, Apr 24, 2009 at 6:37 PM, Boris Zbarsky bzbar...@mit.edu wrote: Ojan Vafai wrote: A workable system that improves on the current state should *at least* return disconnectable handles, and hopefully also provide some way to query join points for connections from both global function objects and scoped function objects. That is to say, it should be possible to do: What?
Re: [whatwg] Exposing EventTarget to JavaScript
Alex Russell slightly...@google.com wrote: But if you addEventListener, you can have multiple listeners for a given event. The only caveat is that dispatch order is undefined. w Also a bug. It's not *actually* undefined, it's triangulated by libraries. Actually, it is defined. They are called in registration order, from oldest to newest. This is stated in both the latest D3E working draft, and the older versions dating back to 2003 (at least - I didn't go back any further) -- Stewart Brodie Software Engineer ANT Software Limited
Re: [whatwg] Exposing EventTarget to JavaScript
Stewart Brodie wrote: Actually, it is defined. They are called in registration order, from oldest to newest. This is stated in both the latest D3E working draft, and the older versions dating back to 2003 (at least - I didn't go back any further) Perhaps I should have been clearer. It's not defined in DOM2 Events, which is what browsers implement in practice. I'm not aware of any browser at this point that's even trying to track the DOM3 Events drafts, yet. -Boris
Re: [whatwg] Exposing EventTarget to JavaScript
On Thu, Apr 30, 2009 at 8:57 AM, Boris Zbarsky bzbar...@mit.edu wrote: Stewart Brodie wrote: Actually, it is defined. They are called in registration order, from oldest to newest. This is stated in both the latest D3E working draft, and the older versions dating back to 2003 (at least - I didn't go back any further) Perhaps I should have been clearer. It's not defined in DOM2 Events, which is what browsers implement in practice. I'm not aware of any browser at this point that's even trying to track the DOM3 Events drafts, yet. IE's attachEvent does not guarantee order, either. | If you attach multiple functions to the same event on the | same object, the functions are called in random order, | immediately after the object's event handler is called. http://msdn.microsoft.com/en-us/library/ms536343(VS.85).aspx Many event registration objects (the javascript libraries) use a combination of addEventListener and attachEvent, where available, so order could not be expected to be consistent, between objects (custom object) or browser. Garrett
Re: [whatwg] Exposing EventTarget to JavaScript
Alex Russell wrote:
Listeners in other languages can/should just be wrapped for purposes
of sanity.
With the wrappers enforcing whatever event type constraints the
listeners are assuming, presumably?
I can totally get behind a handleEvent protocol
I'm not sure what there is to get behind; { handleEvent: function() {} }
is a perfectly good argument to addEventListener in JS right now.
OK. That makes some sense, assuming that the common case is that there is
in fact at most one ancestor. I don't have any data on whether this is
the common case; is it?
Dunno. Regardless, this interface shouldn't support more than one = )
OK, but the real question is whether one is useful enough to bother with
or whether zero is fine too.
That still doesn't answer my question. You need such chaining in the DOM,
say, if you use the on* properties. But if you addEventListener, you can
have multiple listeners for a given event. The only caveat is that dispatch
order is undefined.
Also a bug. It's not *actually* undefined, it's triangulated by
libraries. From the perspective of a browser author, that's just a
cop-out with a standards-body oversight acting as a shield.
Fine, but that doesn't address my question. If addEventListener
guaranteed dispatch order, why would you ever need the library chaining
thing?
So again, is the goal to have multiple listeners per
event, or to be able to enforce a specific ordering on them?
Yes. (Less obtusely, both).
OK; and just making dispatch order defined would not be sufficient?
-Boris
Re: [whatwg] Exposing EventTarget to JavaScript
Sorry I didn't see this earlier.
On Fri, Apr 24, 2009 at 6:32 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Alex Russell wrote:
2) It's not clear what the enumeration should actually return.
EventListener objects? JS Function objects? Something else?
Last I checked people couldn't even agree on this (both have
pros and cons).
Array of function objects.
What about event listeners that are not backed by a JS function? Say actual
objects in JS with a handleEvent function, or listeners implemented in other
languages?
Listeners in other languages can/should just be wrapped for purposes
of sanity. I can totally get behind a handleEvent protocol, but I'm
unclear how it would be different from the .call protocol.
And other than a debugger, I have yet to see a usecase for this. Do you
have a specific one in mind?
Even in the XHR case, adding more than one listener is currently a
pain.
How so, exactly?
Aaron's note about addEventListener solves it, but in the common case
where a JS system wants to have multiple callbacks, they either wind
up carrying around their own event listener system (e.g.,
dojo.connect()) or a Deferred pattern to wrap functions which only
support direct dispatch from a single call site.
It's still not clear to me what that has to do with the questions I asked...
Nevermind...
The only natural thing in DOM is the event flow from target to root. That
concept doesn't make much sense in the absence of a linear data structure
(the list of ancestors, here).
I think what I'd like to see is a way for this interface to allow
arbitrary JS object to specify what their ancestor is. That way
hierarchical JS objects can dispatch up.
OK. That makes some sense, assuming that the common case is that there is
in fact at most one ancestor. I don't have any data on whether this is
the common case; is it?
Dunno. Regardless, this interface shouldn't support more than one = )
Is your real use case just to call a bunch of listeners in a defined
order?
...
Other systems have similar conveniences, but in general they all exist
to keep developers from needing to do:
(function() {
var old_happened = thinger.happened;
thinger.happened = function() {
// ...
return old_happened.apply(this, arguments);
That still doesn't answer my question. You need such chaining in the DOM,
say, if you use the on* properties. But if you addEventListener, you can
have multiple listeners for a given event. The only caveat is that dispatch
order is undefined.
Also a bug. It's not *actually* undefined, it's triangulated by
libraries. From the perspective of a browser author, that's just a
cop-out with a standards-body oversight acting as a shield. Some
libraries add a single listener and then iterate over their own
dispatch list, thereby guaranteeing order.
So again, is the goal to have multiple listeners per
event, or to be able to enforce a specific ordering on them?
Yes. (Less obtusely, both).
Regards
If the latter,
would simply requiring dispatch in addition order (which is, after all
exactly what your example above does) be sufficient?
This method of building callbacks on existing APIs is not, to use
your word, sane.
Oh, absolutely agreed.
-Boris
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 6:37 PM, Boris Zbarsky bzbar...@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.
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...
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);
or some such.
FWIW, dojo.connect() provides a nearly identical scheme to work around
this very problem. For example, you can do:
var handle = dojo.connect(node, onclick, function(){ ... });
// or:
//var handle = dojo.connect(node, onclick, object, method);
//
// ... time passes ...
dojo.disconnect(handle);
This isn't quite satisfying since the case of JS dispatch and using
methods from objects introduces the inevitable functions-aren't-bound
ambiguity in today's JS. We can't, for example, do something like:
var handle = dojo.lookupHandle(node, onclick, object, method);
Since internally we do the turn methods into bound callers trick via
dojo.hitch() (aka, es5's Function.prototype.bind()).
A workable system that improves on the current state should *at least*
return disconnectable handles, and hopefully also provide some way to
query join points for connections from both global function objects
and scoped function objects. That is to say, it should be possible to
do:
nodeOrObject.unlisten(onclick, object, method);
// or:
nodeOrObject.unlisten(onclick, object.method.bind());
Regards
Re: [whatwg] Exposing EventTarget to JavaScript
On Sat, 25 Apr 2009 04:29:09 +0200, Ojan Vafai o...@chromium.org wrote: 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? Note that per DOM Level 3 Events (still a draft) the dispatch order is defined (register order). I believe that is also required for Web compat at this point, though I'm not a 100% sure. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 2:42 PM, Boris Zbarsky bzbar...@mit.edu wrote: Alex Russell wrote: Something missing from this (and from Erik's original mail) is the ability to enumerate listeners. This has been brought up before. Incidentally I just posted a message over at public-webapps about exactly this feature (I discovered this thread afterwards): http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0345.html I'd be happy to continue this discussion here or there, whichever is suitable for everybody else. Best regards Mike Wilson
[whatwg] Exposing EventTarget to JavaScript
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').
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.
One more thing needs to be mentioned and that is how event propagation
should work in scenario. If the object has a parentNode property
then the event dispatching mechanism will do the right thing.
var o1 = new MyClass;
var o2 = new MyClass;
o1.parentNode = o2;
o2.addEvengListener('foo', fun, true); // capture
o1.dispatchEvent(e);
In this case fun will be called because the event propagated up to o2.
There is one more thing that needs to be done to make this work
without a hitch and that is to allow new Event('foo') to work.
Without that we would still have to do var $tmp =
document.createEvent('Event'); $tmp.initEvent('foo') which of course
is very verbose and requires a document.
I see this as a small step to make JS and DOM work better together and
I hope that this is the beginning of a beautiful friendship.
*[1] This can be optimized using js tricks in ES3 and using
Object.create in ES5 so that no EventTarget needs to be instantiated.
--
erik
Re: [whatwg] Exposing EventTarget to JavaScript
As a reminder, the syntax {new Option()} (Netscape DOM) is deprecated to the
syntax {document.createElement(OPTION)} (W3C DOM). The requested syntax
{new Event()} would be inconsistent with that design decision. OTOH, the
syntax {new XMLHTTPRequest()} has already been adopted, perhaps because
{document.createXMLHTTPRequest()} would be too specific?
A bit confused,
Chris
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 10:00 AM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
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.
As we discussed off-list, I absolutely support this, but with shorter
names. The DOM names for these interfaces are dumb. Idiomatic JS
prefers short over long, so the above example should be able to be
written as:
var et = new EventTarget();
et.listen(foo, fun); // default phase to false
et.dispatch(evtObj);
Similarly, the DOM interface should be modified to allow these aliases
for the existing names.
Regards
The example above actually works today if you replace new
EventTarget with document.createElement('div').
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.
One more thing needs to be mentioned and that is how event propagation
should work in scenario. If the object has a parentNode property
then the event dispatching mechanism will do the right thing.
var o1 = new MyClass;
var o2 = new MyClass;
o1.parentNode = o2;
o2.addEvengListener('foo', fun, true); // capture
o1.dispatchEvent(e);
In this case fun will be called because the event propagated up to o2.
There is one more thing that needs to be done to make this work
without a hitch and that is to allow new Event('foo') to work.
Without that we would still have to do var $tmp =
document.createEvent('Event'); $tmp.initEvent('foo') which of course
is very verbose and requires a document.
I see this as a small step to make JS and DOM work better together and
I hope that this is the beginning of a beautiful friendship.
*[1] This can be optimized using js tricks in ES3 and using
Object.create in ES5 so that no EventTarget needs to be instantiated.
--
erik
Re: [whatwg] Exposing EventTarget to JavaScript
2009/4/24 Erik Arvidsson erik.arvids...@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.
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)
One more thing needs to be mentioned and that is how event propagation
should work in scenario. If the object has a parentNode property
then the event dispatching mechanism will do the right thing.
var o1 = new MyClass;
var o2 = new MyClass;
o1.parentNode = o2;
o2.addEvengListener('foo', fun, true); // capture
o1.dispatchEvent(e);
In this case fun will be called because the event propagated up to o2.
There is one more thing that needs to be done to make this work
without a hitch and that is to allow new Event('foo') to work.
Without that we would still have to do var $tmp =
document.createEvent('Event'); $tmp.initEvent('foo') which of course
is very verbose and requires a document.
I see this as a small step to make JS and DOM work better together and
I hope that this is the beginning of a beautiful friendship.
Why do you need an EventTarget?
In most cases you can emulate the same behavior with a Javascript
library, without more work on the UA.
*[1] This can be optimized using js tricks in ES3 and using
Object.create in ES5 so that no EventTarget needs to be instantiated.
--
erik
Giovanni
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 10:30 AM, Giovanni Campagna
scampa.giova...@gmail.com wrote:
2009/4/24 Erik Arvidsson erik.arvids...@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.
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.
Regards
One more thing needs to be mentioned and that is how event propagation
should work in scenario. If the object has a parentNode property
then the event dispatching mechanism will do the right thing.
var o1 = new MyClass;
var o2 = new MyClass;
o1.parentNode = o2;
o2.addEvengListener('foo', fun, true); // capture
o1.dispatchEvent(e);
In this case fun will be called because the event propagated up to o2.
There is one more thing that needs to be done to make this work
without a hitch and that is to allow new Event('foo') to work.
Without that we would still have to do var $tmp =
document.createEvent('Event'); $tmp.initEvent('foo') which of course
is very verbose and requires a document.
I see this as a small step to make JS and DOM work better together and
I hope that this is the beginning of a beautiful friendship.
Why do you need an EventTarget?
In most cases you can emulate the same behavior with a Javascript
library, without more work on the UA.
*[1] This can be optimized using js tricks in ES3 and using
Object.create in ES5 so that no EventTarget needs to be instantiated.
--
erik
Giovanni
Re: [whatwg] Exposing EventTarget to JavaScript
2009/4/24 Alex Russell slightly...@google.com:
On Fri, Apr 24, 2009 at 10:30 AM, Giovanni Campagna
scampa.giova...@gmail.com wrote:
2009/4/24 Erik Arvidsson erik.arvids...@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
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?)
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? This is not the
opinion of the SVGWG, in SVGTiny12.
And Java bindings are provided by WebIDL and all DOM specifications.
Regards
One more thing needs to be mentioned and that is how event propagation
should work in scenario. If the object has a parentNode property
then the event dispatching mechanism will do the right thing.
var o1 = new MyClass;
var o2 = new MyClass;
o1.parentNode = o2;
o2.addEvengListener('foo', fun, true); // capture
o1.dispatchEvent(e);
In this case fun will be called because the event propagated up to o2.
There is one more thing that needs to be done to make this work
without a hitch and that is to allow new Event('foo') to work.
Without that we would still have to do var $tmp =
document.createEvent('Event'); $tmp.initEvent('foo') which of course
is very verbose and requires a document.
I see this as a small step to make JS and DOM work better together and
I hope that this is the beginning of a beautiful friendship.
Why do you need an EventTarget?
In most cases you can emulate the same behavior with a Javascript
library, without more work on the UA.
*[1] This can be optimized using js tricks in ES3 and using
Object.create in ES5 so that no EventTarget needs to be instantiated.
--
erik
Giovanni
Re: [whatwg] Exposing EventTarget to JavaScript
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? 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). - a
Re: [whatwg] Exposing EventTarget to JavaScript
Erik Arvidsson wrote:
To help out with this scenario
it would be good if an implementation of the EventTarget interface
could be exposed to JavaScript.
Why do you want the eventTarget interface as opposed to a sane callback
function registration setup?
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]
So this already works, no?
One more thing needs to be mentioned and that is how event propagation
should work in scenario. If the object has a parentNode property
then the event dispatching mechanism will do the right thing.
What, precisely, is the use case for this in general? In the DOM,
propagating events to parents makes sense (esp. because parents are
unique). What would be the use case in a general object graph?
There is one more thing that needs to be done to make this work
without a hitch and that is to allow new Event('foo') to work.
Without that we would still have to do var $tmp =
document.createEvent('Event'); $tmp.initEvent('foo') which of course
is very verbose and requires a document.
Possibly for good reasons? In some implementations the document is in
fact baked into the event for various security purposes.
I see this as a small step to make JS and DOM work better together and
I hope that this is the beginning of a beautiful friendship.
It's not really clear to me what the benefits of using the (rather
suboptimal, from the JS point of view) DOM EventTarget API for generic
JS callback dispatch are.
-Boris
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, 24 Apr 2009, Erik Arvidsson wrote:
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.
This seems like a reasonable idea, but would be more appropriately made
available in the DOM3 Events specification, being developed in the W3C
public-webapps working group.
On Fri, 24 Apr 2009, Kristof Zelechovski wrote:
As a reminder, the syntax {new Option()} (Netscape DOM) is deprecated to the
syntax {document.createElement(OPTION)} (W3C DOM).
This isn't correct; new Option() is perfectly valid and not deprecated.
On Fri, 24 Apr 2009, Alex Russell wrote:
As we discussed off-list, I absolutely support this, but with shorter
names. The DOM names for these interfaces are dumb. Idiomatic JS prefers
short over long, so the above example should be able to be written as:
var et = new EventTarget();
et.listen(foo, fun); // default phase to false
et.dispatch(evtObj);
Similarly, the DOM interface should be modified to allow these aliases
for the existing names.
I encourage you to bring this up on the public-webapps list.
On Fri, 24 Apr 2009, Giovanni Campagna wrote:
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 does not appear to be accurate either, though DOM3 Events maybe needs
to be made clearer on the topic.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 11:46, Boris Zbarsky bzbar...@mit.edu wrote: It's not really clear to me what the benefits of using the (rather suboptimal, from the JS point of view) DOM EventTarget API for generic JS callback dispatch are. One of the benefits is a consistent API. I do agree that the EventTarget API is suboptimal and so are most of the DOM APIs but it is what we got and we need tie the lose ends and make ends meet. -- erik
Re: [whatwg] Exposing EventTarget to JavaScript
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. 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. 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
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 10:58 AM, Giovanni Campagna
scampa.giova...@gmail.com wrote:
2009/4/24 Alex Russell slightly...@google.com:
On Fri, Apr 24, 2009 at 10:30 AM, Giovanni Campagna
scampa.giova...@gmail.com wrote:
2009/4/24 Erik Arvidsson erik.arvids...@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
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 2:09 PM, Alex Russell slightly...@google.com wrote: 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. Nit: I believe this has been fixed in XHR (it now supports addEventListener, if that's what you were referring to). - a
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 2:16 PM, Aaron Boodman a...@google.com wrote: On Fri, Apr 24, 2009 at 2:09 PM, Alex Russell slightly...@google.com wrote: 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. Nit: I believe this has been fixed in XHR (it now supports addEventListener, if that's what you were referring to). Ahh, yeah, thanks for the clarification. I wasn't aware of that change. Regards
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 11:46 AM, Boris Zbarsky bzbar...@mit.edu wrote:
Erik Arvidsson wrote:
To help out with this scenario
it would be good if an implementation of the EventTarget interface
could be exposed to JavaScript.
Why do you want the eventTarget interface as opposed to a sane callback
function registration setup?
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]
So this already works, no?
One more thing needs to be mentioned and that is how event propagation
should work in scenario. If the object has a parentNode property
then the event dispatching mechanism will do the right thing.
What, precisely, is the use case for this in general? In the DOM,
propagating events to parents makes sense (esp. because parents are unique).
What would be the use case in a general object graph?
Most of the JS object graphs that you'll see in the wild either
represent data hierarchies (wherein updates might trigger a UI change)
or wrapped sets of DOM nodes as a way to make up for the fact that you
can't freaking subclass Element from JS. In the latter case, it's
natural to need it to keep up the facade. In the former, it's a
performance convenience.
There is one more thing that needs to be done to make this work
without a hitch and that is to allow new Event('foo') to work.
Without that we would still have to do var $tmp =
document.createEvent('Event'); $tmp.initEvent('foo') which of course
is very verbose and requires a document.
Possibly for good reasons? In some implementations the document is in fact
baked into the event for various security purposes.
I think individual call sites overriding their dispatch is sane, but
hopefully uncommon.
I see this as a small step to make JS and DOM work better together and
I hope that this is the beginning of a beautiful friendship.
It's not really clear to me what the benefits of using the (rather
suboptimal, from the JS point of view) DOM EventTarget API for generic JS
callback dispatch are.
I don't think the proposal would be to use it as-is. Clearly it needs
beefing up to serve as a good aspect system for JS, but it's the right
starting place. Treating function calls as message sends or events to
be dispatched gives you a nice way of building after-advice into JS
objects, and with a little bit of massaging, could also give you
before and around advice. There's some friction between the Event
object and the arguments object, but not so much that it would be
insurrmountable to recast DOM event dispatch as sub-case of regular JS
function calling. JS libraries provide ways to try to unify these
interfaces (at huge expense), so moving it into the language makes the
most sense.
Regards
Re: [whatwg] Exposing EventTarget to JavaScript
Alex Russell wrote: Something missing from this (and from Erik's original mail) is the ability to enumerate listeners. This has been brought up before. 1) There are some serious security concerns here. 2) It's not clear what the enumeration should actually return. EventListener objects? JS Function objects? Something else? Last I checked people couldn't even agree on this (both have pros and cons). And other than a debugger, I have yet to see a usecase for this. Do you have a specific one in mind? Even in the XHR case, adding more than one listener is currently a pain. How so, exactly? Part of the goal here would be to make event dispatch across lists of listeners as natural in JS as it is in DOM. The only natural thing in DOM is the event flow from target to root. That concept doesn't make much sense in the absence of a linear data structure (the list of ancestors, here). Is your real use case just to call a bunch of listeners in a defined order? -Boris
Re: [whatwg] Exposing EventTarget to JavaScript
Erik Arvidsson wrote: On Fri, Apr 24, 2009 at 11:46, Boris Zbarsky bzbar...@mit.edu wrote: It's not really clear to me what the benefits of using the (rather suboptimal, from the JS point of view) DOM EventTarget API for generic JS callback dispatch are. One of the benefits is a consistent API. OK, true. But if the API is a bad fit, this might not be enough to want to use it. I do agree that the EventTarget API is suboptimal and so are most of the DOM APIs but it is what we got and we need tie the lose ends and make ends meet. Why is the right approach to this to add addEventListener and its baggage to everything instead of adding a sane API to everything? -Boris
Re: [whatwg] Exposing EventTarget to JavaScript
Alex Russell wrote: Most of the JS object graphs that you'll see in the wild either represent data hierarchies (wherein updates might trigger a UI change) or wrapped sets of DOM nodes as a way to make up for the fact that you can't freaking subclass Element from JS. In the latter case, it's natural to need it to keep up the facade. In the former, it's a performance convenience. Agreed for the latter case (though at that point whatever is doing the wrapping can also handle forwarding the listener sets to the real DOM nodes). I'm not sure what the performance issue with the former case is. Can you elaborate? Possibly for good reasons? In some implementations the document is in fact baked into the event for various security purposes. I think individual call sites overriding their dispatch is sane, but hopefully uncommon. I'm not sure how that relates to what I said... It's not really clear to me what the benefits of using the (rather suboptimal, from the JS point of view) DOM EventTarget API for generic JS callback dispatch are. I don't think the proposal would be to use it as-is. OK. -Boris
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 2:42 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Alex Russell wrote:
Something missing from this (and from Erik's original mail) is the
ability to enumerate listeners.
This has been brought up before.
1) There are some serious security concerns here.
2) It's not clear what the enumeration should actually return.
EventListener objects? JS Function objects? Something else?
Last I checked people couldn't even agree on this (both have
pros and cons).
Array of function objects. That would let you do useful things with it
like unshifting onto the front or slicing to remove some set of
listeners.
And other than a debugger, I have yet to see a usecase for this. Do you
have a specific one in mind?
Even in the XHR case, adding more than one listener is currently a
pain.
How so, exactly?
Aaron's note about addEventListener solves it, but in the common case
where a JS system wants to have multiple callbacks, they either wind
up carrying around their own event listener system (e.g.,
dojo.connect()) or a Deferred pattern to wrap functions which only
support direct dispatch from a single call site.
Part of the goal here would be to make event dispatch across
lists of listeners as natural in JS as it is in DOM.
The only natural thing in DOM is the event flow from target to root. That
concept doesn't make much sense in the absence of a linear data structure
(the list of ancestors, here).
I think what I'd like to see is a way for this interface to allow
arbitrary JS object to specify what their ancestor is. That way
hierarchical JS objects can dispatch up.
Is your real use case just to call a bunch of listeners in a defined order?
Consider some API that defines an event:
thinger = {
happened: function(){
// processes some state here
}
};
Today, JS toolkits provide various ways of listening for something
invoking this. In Dojo, I'd say:
dojo.connect(thinger, happened, function(){ ... });
Other systems have similar conveniences, but in general they all exist
to keep developers from needing to do:
(function() {
var old_happened = thinger.happened;
thinger.happened = function() {
// ...
return old_happened.apply(this, arguments);
};
})();
This method of building callbacks on existing APIs is not, to use
your word, sane.
Regards
Re: [whatwg] Exposing EventTarget to JavaScript
Forwarded to public-weba...@w3.org
On Fri, Apr 24, 2009 at 14:52, Alex Russell slightly...@google.com wrote:
On Fri, Apr 24, 2009 at 2:42 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Alex Russell wrote:
Something missing from this (and from Erik's original mail) is the
ability to enumerate listeners.
This has been brought up before.
1) There are some serious security concerns here.
2) It's not clear what the enumeration should actually return.
EventListener objects? JS Function objects? Something else?
Last I checked people couldn't even agree on this (both have
pros and cons).
Array of function objects. That would let you do useful things with it
like unshifting onto the front or slicing to remove some set of
listeners.
And other than a debugger, I have yet to see a usecase for this. Do you
have a specific one in mind?
Even in the XHR case, adding more than one listener is currently a
pain.
How so, exactly?
Aaron's note about addEventListener solves it, but in the common case
where a JS system wants to have multiple callbacks, they either wind
up carrying around their own event listener system (e.g.,
dojo.connect()) or a Deferred pattern to wrap functions which only
support direct dispatch from a single call site.
Part of the goal here would be to make event dispatch across
lists of listeners as natural in JS as it is in DOM.
The only natural thing in DOM is the event flow from target to root. That
concept doesn't make much sense in the absence of a linear data structure
(the list of ancestors, here).
I think what I'd like to see is a way for this interface to allow
arbitrary JS object to specify what their ancestor is. That way
hierarchical JS objects can dispatch up.
Is your real use case just to call a bunch of listeners in a defined order?
Consider some API that defines an event:
thinger = {
happened: function(){
// processes some state here
}
};
Today, JS toolkits provide various ways of listening for something
invoking this. In Dojo, I'd say:
dojo.connect(thinger, happened, function(){ ... });
Other systems have similar conveniences, but in general they all exist
to keep developers from needing to do:
(function() {
var old_happened = thinger.happened;
thinger.happened = function() {
// ...
return old_happened.apply(this, arguments);
};
})();
This method of building callbacks on existing APIs is not, to use
your word, sane.
Regards
--
erik
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 2:43 PM, Boris Zbarsky bzbar...@mit.edu wrote: Erik Arvidsson wrote: I do agree that the EventTarget API is suboptimal and so are most of the DOM APIs but it is what we got and we need tie the lose ends and make ends meet. Why is the right approach to this to add addEventListener and its baggage to everything instead of adding a sane API to everything? What would be a better approach? You gain a lot from consistency and doing something that developers are already intimately familiar with. Personally, addEventListener seems good enough to me and it's already there. I'm not totally opposed to coming up with something better than addEventListener, but it's hard to argue one way or another without a counter-proposal. Ojan
Re: [whatwg] Exposing EventTarget to JavaScript
Alex Russell wrote:
2) It's not clear what the enumeration should actually return.
EventListener objects? JS Function objects? Something else?
Last I checked people couldn't even agree on this (both have
pros and cons).
Array of function objects.
What about event listeners that are not backed by a JS function? Say
actual objects in JS with a handleEvent function, or listeners
implemented in other languages?
And other than a debugger, I have yet to see a usecase for this. Do you
have a specific one in mind?
Even in the XHR case, adding more than one listener is currently a
pain.
How so, exactly?
Aaron's note about addEventListener solves it, but in the common case
where a JS system wants to have multiple callbacks, they either wind
up carrying around their own event listener system (e.g.,
dojo.connect()) or a Deferred pattern to wrap functions which only
support direct dispatch from a single call site.
It's still not clear to me what that has to do with the questions I asked...
The only natural thing in DOM is the event flow from target to root. That
concept doesn't make much sense in the absence of a linear data structure
(the list of ancestors, here).
I think what I'd like to see is a way for this interface to allow
arbitrary JS object to specify what their ancestor is. That way
hierarchical JS objects can dispatch up.
OK. That makes some sense, assuming that the common case is that there
is in fact at most one ancestor. I don't have any data on whether
this is the common case; is it?
Is your real use case just to call a bunch of listeners in a defined order?
...
Other systems have similar conveniences, but in general they all exist
to keep developers from needing to do:
(function() {
var old_happened = thinger.happened;
thinger.happened = function() {
// ...
return old_happened.apply(this, arguments);
That still doesn't answer my question. You need such chaining in the
DOM, say, if you use the on* properties. But if you addEventListener,
you can have multiple listeners for a given event. The only caveat is
that dispatch order is undefined. So again, is the goal to have
multiple listeners per event, or to be able to enforce a specific
ordering on them? If the latter, would simply requiring dispatch in
addition order (which is, after all exactly what your example above
does) be sufficient?
This method of building callbacks on existing APIs is not, to use
your word, sane.
Oh, absolutely agreed.
-Boris
Re: [whatwg] Exposing EventTarget to JavaScript
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.
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...
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);
or some such.
-Boris
Re: [whatwg] Exposing EventTarget to JavaScript
Ojan Vafai wrote: 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. Those are unrelated issues, aren't they? The linear list I was referring to is the proposed parentNode (or equivalent) chain; order there is well-defined, presumably. For each element in this list, one can have multiple listeners for the event; the dispatch order here is currently undefined, but that could be changed. Is there a reason that they can't dispatch in a guaranteed order? You'd probably have to check with the folks who wrote DOM2 Events, if the question is why the spec says what it says. If the question is about current implementations, nothing obvious jumps out at me in the one implementation I'm familiar with (Gecko's). -Boris
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 6:37 PM, Boris Zbarsky bzbar...@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
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 7:26 PM, Boris Zbarsky bzbar...@mit.edu wrote: Ojan Vafai wrote: 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. Those are unrelated issues, aren't they? The linear list I was referring to is the proposed parentNode (or equivalent) chain; order there is well-defined, presumably. For each element in this list, one can have multiple listeners for the event; the dispatch order here is currently undefined, but that could be changed. Sorry, I had misread this. Although, I think a linear list of things the event is targeting is sufficient. Is there a reason that they can't dispatch in a guaranteed order? You'd probably have to check with the folks who wrote DOM2 Events, if the question is why the spec says what it says. If the question is about current implementations, nothing obvious jumps out at me in the one implementation I'm familiar with (Gecko's). Yeah, I'm more interested in implementation difficulties. I can't think of anything obvious in WebKit's implementation either, but I'm not too familiar with the event handling code. Ojan
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 2:59 PM, Ojan Vafai o...@chromium.org wrote: On Fri, Apr 24, 2009 at 2:43 PM, Boris Zbarsky bzbar...@mit.edu wrote: Erik Arvidsson wrote: I do agree that the EventTarget API is suboptimal and so are most of the DOM APIs but it is what we got and we need tie the lose ends and make ends meet. Why is the right approach to this to add addEventListener and its baggage to everything instead of adding a sane API to everything? What would be a better approach? Turning an interface into a class doesn't make any sense at all. EventTarget is an interface. It would be trivial to create a new DOM object that implements EventTarget. Boris pointed out that there are some problems with addEventListener. Lets not ignore those. Trying to shoehorn an existing API to accomodate new functionality, in light of existing problems sounds like a bad idea. EventTarget should not become a Constructor. You gain a lot from consistency and doing something that developers are already intimately familiar with. Changing EventTarget from an interface into a Constructor would create less consistency in the behavior of instances implementing (or Extending) EventTarget, would result in less consistency in the expected behavior of such objects, and would reduce consistency in the EventTarget interface (old vs new). If you want consistency in an API, use a different one. The new one ignore |useCapture|, so clients wanting to use both could use duckTyping. Garrett
