Re: Dropping (or deprecating) event initialization methods

Hi, Folks-

Garrett Smith wrote (on 9/18/09 1:46 PM):
> On 9/18/09, Morten Barklund<morten@barklund.dk>  wrote:
>>
>>   >     * adding attributes to a parent interface, like UIEvent, would mean
>>   >       that the intuitive argument order could not be kept in the child
>>   >       interface's method
>>
>>  I find this to be the biggest problem.
>>
>>   If arguments of init-methods should be in order of attributes from each of
>>   the interfaces in the inheritance chain in inheritance order, you
>>   essentially either have to settle with the interfaces currently available
>>   ("for all eternity") or change the argument order every time an interface
>>   is changed and breaking backwards compatibility - or once and for all
>>   change the initialization pattern used.
>>
>>   >  I suggest that we dispense with this pattern, and instead make all of
>>   >  the attributes that these initializer methods would set writable.  If
>>   >  assigned to during event dispatch, an exception would be thrown.
>
> The pattern can't be forgotten. It is in widespread use. The existing
> methods are not extensible, but they can't be just removed.
>
> The existing API can be refactored to a more extensible design, while
> preserving the (baroque) initMouseEvent.

Agreed.  I would not remove the per-interface init events (though I 
might deprecate them), and would introduce one or more extensible models 
as suggested.


> This makes it easy for scripts to transition to the new methods using
> feature detection.

I think yoking the topic of event initialization and feature detection 
somewhat muddles the discussion.  Let's have two different threads about 
these topics, please.


>>  I see two combinable solutions. Either create initMethods that take
>>   dictionaries of attributes like:
>>
>>   document.initMouseEvent({target: foo, relatedTarget: bar});
>
> That is what I proposed. Here:-
> http://lists.w3.org/Archives/Public/www-dom/2009JulSep/0164.html
>   * createInitedEvent
...
>
> The discussion had several useful comments from Olli Pettay who
> suggested/helped elicit:
>   * dispatchInitedEvent
...
>
> Method createInitedEvent would take an object and, for each property,
> set a value on the event.
...
>>   And/or make attributes settable during the event initialization phase and
>>   lock them down once the event is dispatched as Cameron suggests. Both are
>>   tricky ways to implement in some languages and easy in others. Using the
>>   dictionary approach is though possible with the current possibilities in
>>   the Web IDL language, but it is a foreign concept still.

We could specify both methods, and if one can't be implemented in some 
language, so be it... people writing in that language can use the other 
method.

Which languages might have difficulties with which method?


> The problem with allowing properties to be settable is that it
> introduces an incompatibility. This is bad for two reasons:
>   * implementors have to immediately change so they can stop throwing errors
>   * developers will use the feauture, testing maybe three or four
> latest browsers and causing errors in implementations today.

We might be able to overcome this problem by making a wrapper that 
emulates the new behavior in older browsers.

Something that has been talked about during telcons, and which I would 
like to pursue when we are in CR, is to produce a DOM3Events script 
library, which emulates as much functionality of DOM3 Events in a 
cross-browser manner as possible (which should actually be quite a bit). 
  This way, people can start using the standard DOM3 Events methods and 
events immediately across the board, and it could work in older browsers 
as well as browsers with native implementation.

(Note that we could list this script lib in the implementation matrix, 
but we would still want 2 native browser implementations of each feature 
as part of our CR exit criteria).

But to be frank, at some point, users simply have to upgrade their 
browsers.  New features are inherently disruptive, and fallback 
solutions only take you so far.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Friday, 18 September 2009 19:24:02 UTC