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

Regarding event constructors, the draft Jacob wrote looks great to me.

http://html5labs.com/dom4events/

If we have consensus on the spec, I think that we should move forward
to publishing it at w3.org and progressing it towards a standard.


>>> 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.

I think this feature would be controversial. I suggest that we move
forward to publishing the spec without adding the feature for now.
Practically, I feel that we should not block the work to define event
constructors by discussions around the new features.

People have been hoping for event constructors, especially for
MouseEvent and KeyboardEvent, because they are widely used and their
init{Mouse,Keyboard}Event(...) have soooo many arguments. In addition,
other Events (i.e. Event, CustomEvent, ProgressEvent, HashChangeEvent,
MessageEvent, ErrorEvent, PageTransitionEvent, PopStateEvent and
CloseEvent) already have constructors in their specs.


Best Regards


On Tue, Jan 24, 2012 at 10:13 PM, Alex Russell <slightlyoff@chromium.org> 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.
>>
>> 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').
>
> I'm not seeing an argument anywhere in here for *why* it's not a good
> idea to expose this, only that you believe in the current model.
> What's the actual impact? If it's security, the list of registered
> handlers exposed to content doesn't have to surface UA-private
> handlers.
>
> Regards
>
>>> 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.   `._.-(,_..'--(,_..'`-.;.'
>>



-- 
Kentaro Hara, Tokyo, Japan (http://haraken.info)

Received on Wednesday, 25 January 2012 17:12:58 UTC