[whatwg] Exposing EventTarget to JavaScript

[Boris Zbarsky]

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