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
