[whatwg] Exposing EventTarget to JavaScript

[Alex Russell]

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
>
>