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

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.


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:

[Partial]
interface EventTarget {
  TheEventListeners[] tellMeAllTheEventListeners(DOMString type);
}

interface TheEventListeners {
 readonly attribute any listener;
 readonly attribute boolean useCapture;
}

I've used silly names to avoid dwelling on the exact IDL or behavior.  But the gist is that you could provide a way to get the registered event listeners on a node:

someElement.addEventListener("foo", myListener, false);
someElement.addEventListener("foo", anotherListener, true);
var listeners = someElement.tellMeAllTheEventListeners("foo");
alert("There are " + listeners.length + " listeners to the foo event on this element!");

listeners is an array of objects that provide you a reference to the listener and whether it uses capture or not.  This would, of course, need some definition as to how it behaves with event handler attributes and anonymous functions. But I think we could work something out.

-Jacob

> -----Original Message-----
> From: Ian Hickson [mailto:ian@hixie.ch]
> Sent: Thursday, October 20, 2011 10:09 AM
> To: Jacob Rossi
> Cc: Anne van Kesteren; www-dom@w3.org; schepers@w3.org; Kentaro Hara;
> Dominic Cooney; Adrian Bateman
> Subject: RE: "DOM4 Events" Proposal (was: Spec proposals for Event
> constructors)
> 
> On Thu, 20 Oct 2011, Jacob Rossi wrote:
> >
> > Another feature I've been considering to add to DOM4 Events is the
> > ability to inspect the list of registered event listeners on a node.
> 
> This would break an assumption baked into many parts of the platform. I
> strongly recommend against adding such a feature.
> 
> The assumption is that adding an event listener that doesn't do anything is itself
> a no-op; that there can be no side-effects from such a registration. This
> assumption is used throughout the platform, e.g. event handler attributes, in
> the use of the event model by ATs, etc.
> 
> In any case, the event model is now described in the DOM Core spec, where it
> belongs (due to its interaction with the DOM); I really see no reason to also
> describe it in the DOM Events spec. I strongly recommend just specifying the
> user interaction events like key and mouse events and not defining the model
> or events that are already defined by other specifications (such as 'change' or
> 'input').
> 
> 
> > Or perhaps we could make addEventListener have a return value that
> > indicates native support for the event type?
> 
> What does "native support for the event type" mean?
> 
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 21 October 2011 23:00:32 UTC