Re: Dropping (or deprecating) event initialization methods

On Fri, Sep 18, 2009 at 12:23 PM, Doug Schepers <schepers@w3.org> wrote:
> 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'm not sure what your reason "yoking the topic" means or why you feel
that the new approach does not need feature detection. Please explain
what you mean and how you arrived at the conclusion that feature
detection is not relevant.

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

I don't understand this proposal. Do you mean, by writing and
publishing a script, as described below?

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

How nice that would be!

For any new feature, the problem that is being addressed by that
feature should use a fallback, in case the new feature fails.

Users do not always have a choice to upgrade. Nor do they have always
have a choice of javascript configuration. Among those who do have the
choice to configure javascript, many disable it entirely.

Users who do have a choice may choose not to upgrade, to disable
scripts (either partially or completely), or may choose to not
*enable* javascript.

The number of mobile browsers is probably in the thousands and many of
these have javascript or CSS turned off by default (this may depend on
the carrier). Many of these have browsers that do not support things
as simple as |setTimeout|.

Expecting the new feature to "work" is not fair to web authors or
users. The best you could do would be to provide something that:
1) feature detectible
2) a fallback can be used


If the feature cannot be detected, nor can a reliable inference be
made then the author should not expect it to be implemented.

Garrett

Received on Friday, 18 September 2009 22:01:39 UTC