Re: "DOM4 Events" Proposal (was: Spec proposals for Event constructors)

On Fri, Oct 21, 2011 at 6:59 PM, Jacob Rossi <Jacob.Rossi@microsoft.com>wrote:

> Sorry, I don't follow what you mean by them being a no-op.  Here's what I
> meant for a return value of addEventListener:
>

> if(!someNode.addEventListener("wheel",doZoom,false))
>        someNode.addEventListener("mousewheel",doZoom,false);
>
> Note:  the registration for wheel above still happens because it's entirely
> possible the script might want to fire its own untrusted wheel event. Script
> could, of course, remove the wheel registration since the UA returned false
> indicating it doesn't recognize the wheel event.
>

I don't like this, because it makes script-fired events second-class
compared to events fired by the browser.  Currently, if a browser doesn't
support an event, I can fire it; while it won't mimic a native
implementation entirely (eg. the trusted flag will always be unset), often
it's more than close enough to make existing code work.  That's lost if code
decides not to use an event because of a mechanism like this.  There'd need
to be a mechanism to "register" an event, eg.
window.addSupportedEvent("wheel").

Capturing and bubbling also make this less obvious.  Does this only return
true if the event type can be fired on the element itself?  That'll cause it
to return false even when the event will still be received, during the
capture and/or bubble phases.  If it returns true if *any* event target
might have that type fired on it, then you lose granularity, and risk
compatibility down the line (event types aren't unique).

Also note that this won't work with dynamically-generated event types, eg.
server-sent events.

Thinking further, I don't think my listener inspection idea should be used
> for feature detection. But I do think it's useful (we've seen libraries like
> Jquery try to provide this and it's useful for things like instrumentation).
> Here's an unpolished example of what I meant for event inspection:
>

This is something I've wanted to do more than once; usually for debugging.
I've also wanted it with Greasemonkey scripts, where I want to be able to
patch a site's event listeners.  (The latter use case, at least, may belong
in a UA-specific extension; it's far too brittle to use in production, since
it'll break removeEventListener.)

I understand Ian's concern about side-effects of addEventListener.  Even
recently, APIs have tried to have event registration cause side-effects,
which is misusing DOM Events badly.  WebGL did this, changing a default
behavior if a listener for a particular event type was added.  (This has
been fixed.)  However, I don't think introspection is the same: all
introspection can potentially cause "side-effects", but that generally isn't
considered to be a violation of side-effects invariants.  If it was, we
couldn't have any useful introspection at all.

>
-- 
Glenn Maynard