Feature Detection (was: Dropping (or deprecating) event initialization methods)

Hi, Garrett-

Garrett Smith wrote (on 9/18/09 5:54 PM):
> On Fri, Sep 18, 2009 at 12:23 PM, Doug Schepers<schepers@w3.org>  wrote:
>>
>>  Garrett Smith wrote (on 9/18/09 1:46 PM):
>>>  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

Feature detection is a separate topic in its own right, and applies to 
any new feature, not just event initialization.  While there may be 
multiple feature-detection mechanisms to account for all new features, I 
think that topic is best covered as a separate thread (this one).


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

Obviously, I think feature detection is a good idea, since I made my own 
proposal for it.  However, the browser vendors (and maybe other 
implementers) have not been satisfied with any proposal so far, so I am 
skeptical that we will have something in time for DOM3 Events.

However, I've added a wishlist item, and maybe we can indeed come up 
with something that satisfies all parties well enough to include it:
  http://www.w3.org/2008/webapps/wiki/DOM_Wishlist#General


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

Yes.


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

In some circumstances, there may simply not be a fallback available. 
This is not to say that we shouldn't provide a means for doing so where 
possible, but so far, all the feature-detection proposals are flawed 
with both false positives and false negatives.


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

We're defining script APIs.  If the user doesn't have javascript 
enabled, there is no fallback possible for that case except to simply 
make a scriptless version of the application (perhaps using forms), in 
which case, the DOM3 Events specification is irrelevant.  Even if we did 
define a feature-detection mechanism, it couldn't work in a scriptless 
environment. (Note: SVG does have the <switch> element which can work on 
feature detection and fallbacks for markup, if not script... similarly, 
SVG has SMIL animation which can enable some interactivity even in 
scriptless environments.  SVG is awesome.)

But stepping back... You're too smart a guy to make such a weak argument 
in good faith.  I understand that you are frustrated, and you are 
lashing out with a reductio ad absurdum argument.  This is not 
productive, and it won't make one iota difference in the spec, except to 
decrease the quality of technical dialog, taking time that could be 
spent improving the spec.  This group will consider all reasonable 
proposals, but we won't tolerate wasting our time.  I know you are 
capable of making well-though-out proposals and solid arguments, and we 
do welcome and appreciate your taking the time to do so.  Please respect 
the goals of this group.


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

I appreciate that you're trying to look out for authors... honestly, I 
do.  I personally feel that the best way we can serve authors and users 
is twofold:

1) design a system that works so well that authors can easily make 
compelling content, thus increasing the odds that users will upgrade 
their browsers to take advantage of the content (I understand that this 
takes time for some users, but in the meantime it will serve the 
purposes of a sufficient number of authors and users that it is worthwhile)

2) build a community of implementers that commit to implementing the set 
of features defined in the specification with high interoperability; my 
aim is to define the spec in sufficient detail that it is unambiguous, 
and we have Microsoft and Mozilla actively involved, and it seems every 
other major browser vendor is engaged as well (though a bit less 
vocally), representing a vast amount of market share.

Yes, this does leave a moderate number of users of legacy browser 
versions uncovered, though many of them will be served by the D3E script 
library.  For the others... I'm not convinced that even if we did define 
a bulletproof feature-detection and fallback mechanism, it would be 
totally backward-compatible, nor that it would justify the extra work 
authors would have to exert to reach that long tail.

The most interesting case to me would be to provide a mechanism *now* 
which would enable better feature-detection for future extensions and 
new features.  If anyone has an idea how that could work (and which 
would be better than my favored solution, atomic feature strings), 
please make a solid proposal, and we can lay the foundation for a more 
stable platform going forward.

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

Received on Friday, 18 September 2009 23:00:52 UTC