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

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