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

On Fri, Sep 18, 2009 at 4:49 PM, Garrett Smith <dhtmlkitchen@gmail.com> wrote:
> 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
>

I am not going to reply to the extremely long (and negative) personal
email you sent and I have no idea what the motivation was.

Again, I did not find a problem with my message. There was no malice
intended in it. Really. It may have been something misconstrued. What
exactly was it?

Garrett

Received on Saturday, 19 September 2009 01:42:42 UTC