On Thu, Oct 20, 2011 at 10:09 AM, Ian Hickson <ian@hixie.ch> wrote: > 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. > Can you expand on this? What does it actually affect? Could you get the same effect by saying that addEventListener of a function that doesn't do anything is a noop? That way, the list of registered event listeners would still be empty, but you are able to query the non-noop registered event listeners. > 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 Monday, 24 October 2011 18:31:49 UTC