- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 29 Apr 2009 12:06:43 -0700
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
Received on Wednesday, 29 April 2009 12:06:43 UTC