W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2011

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

From: Jacob Rossi <Jacob.Rossi@microsoft.com>
Date: Wed, 26 Oct 2011 18:18:24 +0000
To: Ojan Vafai <ojan@chromium.org>, Ian Hickson <ian@hixie.ch>
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>
Message-ID: <D0BC8E77E79D9846B61A2432D1BA4EAE035E5B03@TK5EX14MBXC288.redmond.corp.microsoft.com>
On Mon, Oct 24, 2011 at 11:31 AM, Ojan Vafai <ojan@google.com> wrote:> 
> 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.

Yes, please elaborate.  Assuming you mean something like "function () { }" as a "event listener that doesn't do anything," I see this just as an edge case we need to define the behavior for in such inspection APIs. 

>From a pure spec interpretation, "function() {}" is no less of an even listener than "function(e) { alert(e.type); }". I don't see how such a registration is really a no-op. If a script calls addEventListener or sets an event handler attribute with a valid function (empty or not) then I consider that a registration--what the listener does (or doesn't do) when called is its own business. 

It may be that implementations optimize out such registrations. If that's interoperable (and spec'd somewhere), then I would expect these inspection APIs to not return them as 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?

It means the implementation is able to generate *trusted* events of this type. 

However, I do understand the argument that a library might provide support for an event type via untrusted events. So perhaps there might also need to be a way for a script to say "I'm providing support for this new event type" to the implementation so that it can correctly return the value.
Received on Wednesday, 26 October 2011 18:36:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:36:59 UTC