W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2009

[whatwg] Exposing EventTarget to JavaScript

From: Alex Russell <slightlyoff@google.com>
Date: Wed, 29 Apr 2009 11:30:13 -0700
Message-ID: <6fc58d0d0904291130r7da38a0bvf022b570a22f4934@mail.gmail.com>
Sorry I didn't see this earlier.

On Fri, Apr 24, 2009 at 6:32 PM, Boris Zbarsky <bzbarsky at 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
>
>
Received on Wednesday, 29 April 2009 11:30:13 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:11 UTC