Re: Window Modes todo

For the JS framework MooTools, I'm currently implementing a model where you
can pass an object to an event constructor: new Event({ foo: 'bar', foo2:
'bar' });
Any uninitialized properties would fall back to defaults. This would be
comparable to named parameters found in many languages. You could also
compare this to IE's way of cloning an existing event if you pass one to
document.createEventObject.
However, this is very specific to the dynamic nature and object initializers
in JavaScript. So it's not suitable for this specification.

You could use multiple initializers - one for each section of functionality
or inheritance level.

To me, it doesn't make sense to add all the parameters from initEvent to
initUIEvent. A UIEvent inherits Event, so by definition it already has an
optional initializer (initEvent) that can take all those parameters.

DragEvent is pretty horrible:

initEvent(eventTypeArg, canBubbleArg, cancelableArg);

initUIEvent(typeArg, canBubbleArg, cancelableArg, viewArg, detailArg);

initMouseEvent(typeArg, canBubbleArg, cancelableArg, viewArg, detailArg,
> screenXArg, screenYArg, clientXArg, clientYArg, ctrlKeyArg, altKeyArg,
> shiftKeyArg, metaKeyArg, buttonArg, relatedTargetArg);

initDragEvent(typeArg, canBubbleArg, cancelableArg, viewArg, detailArg,
> screenXArg, screenYArg, clientXArg, clientYArg, ctrlKeyArg, altKeyArg,
> shiftKeyArg, metaKeyArg, buttonArg, relatedTargetArg, dataTransferArg);


Each step adds more stuff. It would be more flexible if each one in the
chain was called separately:

initEvent(eventTypeArg, canBubbleArg, cancelableArg);

initUIEvent(viewArg, detailArg);

initMouseEvent(screenXArg, screenYArg, clientXArg, clientYArg, ctrlKeyArg,
> altKeyArg, shiftKeyArg, metaKeyArg, buttonArg, relatedTargetArg);

initDragEvent(dataTransferArg);


Implementations can already handle no init or a lower level init method
being called, in which case the higher level variables reverts to defaults.

But all of this is a very substantial change. One that I don't think is
necessary if there isn't a known need to change the lower level Event
interfaces. It might be that those properties need to allow setters anyway.

Sebastian Markbåge

On Mon, Jul 27, 2009 at 3:59 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> Robin Berjon wrote:
>
>> Do other implementers care to chime in with what they do, and if they'd
>> find this change acceptable?
>>
>
> As I recall Gecko's behavior, it works more or less like this:
>
> 1)  Properties listed as readonly in the DOM 2 Events IDL are in
>    fact readonly.
> 2)  init*Event may be called multiple times, at any point when the
>    event is not in the middle of being dispatched.
> 3)  dispatchEvent may be called multiple times, at any point when
>    the event is not in the middle of being dispatched.
>
> I believe #2 is a violation of the DOM 2 Events specification; I'm not
> quite sure why we allow that.  I think there were some historical reasons,
> but they might not be relevant anymore.  Olli might know more.  The "when
> the event is not in the middle of being dispatched" for dispatchEvent is
> probably technically a violation of that specification too, though it's more
> likely that the issue was simply not considered during the authoring of the
> specification.
>
> -Boris
>
> P.S.  I hope I understood the question correctly...
>
>