W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2009

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

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Fri, 18 Sep 2009 16:49:05 -0700
Message-ID: <c9e12660909181649g1f54a0edpd9517eaf87225ddb@mail.gmail.com>
To: Doug Schepers <schepers@w3.org>
Cc: www-dom@w3.org
On Fri, Sep 18, 2009 at 4:00 PM, Doug Schepers <schepers@w3.org> wrote:
> 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.
>

There does not need to be a proposal for "feature detection".

Feature detection works as:-

if(document.images) {
  var x = new Image(10, 12); // Fair inference.
}

That is feature detection.

Another:-

var ev;
if(document.createInitedEvent) {
  // feature detected.
  ev document.createInitedEvent("mousedown", {clientX:10});

}

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

I am not sure, but it sounds like you have conflated two things that
I've written:
1) any new feature needs to be detectible
2) there should be a way to test to see if an eventTarget fires an event.



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

What makes you say that I am "lashing out"?

So I am wasting your time?

What exactly is your problem here?

New features need to be detectable in some way.

Are we on the same page?

Usually it is not difficult to make a fair inference but it can be
difficult to impossible in other cases. Is PNG alpha channel
supported? Will DOMFocusIn fire? Does setTimeout work? Can the page
open a new window? Will the CSS on the list be applied (this seems to
be an issue in mobile browsers). Is javascript enabled? (Blackberry
curve). Mobile carrier may also alter the settings, install other
browsers with other settings.

Still on the same page?

The more browsers I examine and test, the more I realize how fragile
my code is and the less I trust anything to work.

Feature detection is a really big deal in general. Not just "will an
event fire". Everything.

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

There is loose inference, object detection, and feature tests.

There need not be one overall feature detection mechanism.

For example, when a program encounters an object with an
|addEventListener| property, it can make inferential leaps that the
following are true:-
1) the addEventListener property is callable
2) it will add a callback
3) there will also be a |removeEventListener| property on that object
which removes the callback.

User-agent sniffing is a very loose inference, as the presence/absence
of "MSIE" in the userAgent is unrelated to, say, "onreadystatechange".
This has two problems. The first problem occurs with clients that have
"MSIE" in their userAgent executing the code that is not supported
(possibly resulting in error). The second problem is that it disallows
any client to execute the code that it may be perfectly capable of
running. This second symptom can be seen when a program presents a
"your browser is unsupported" page (Yahoo Mail, for example).

More:
http://dev.opera.com/articles/view/using-capability-detection/

Garrett
Received on Friday, 18 September 2009 23:49:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:03 GMT