- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 20 Oct 2011 17:09:28 +0000 (UTC)
- To: Jacob Rossi <Jacob.Rossi@microsoft.com>
- cc: Anne van Kesteren <annevk@opera.com>, "www-dom@w3.org" <www-dom@w3.org>, "schepers@w3.org" <schepers@w3.org>, Kentaro Hara <haraken@chromium.org>, Dominic Cooney <dominicc@chromium.org>, Adrian Bateman <adrianba@microsoft.com>
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 Thursday, 20 October 2011 17:13:37 UTC