Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > MS recommends "feature detection"

Reply
Thread Tools

MS recommends "feature detection"

 
 
David Mark
Guest
Posts: n/a
 
      06-13-2010
MS has finally started to recommend feature detection.

http://blogs.msdn.com/b/ie/archive/2...wser-code.aspx

It's too bad they are completely clueless about how to go about it.
Their example (slightly modified from jQuery code) is laughable.

If you want to teach feature detection, don't use examples from
jQuery.

And from the comments, this is why the average Web developer will
never understand why browser detection is unnecessary:-

"On IE there exists "navigator.plugins" but it is always empty."

They answered their own objection, didn't they?

Another one:-

http://blogs.msdn.com/b/ie/archive/2...-elements.aspx

More jQuery-style object inferences. Lots of valid objections in the
comments, but diluted by typically clueless "answers" like this one:-

"In the case of a recipe like the one Tony posted, it's been found to
work on enough browsers to be quite practical, and it's pretty
simple. "Actually correct programming methods" involve a little
compromise when you just don't know what environment will be running
your code."

Found to work on enough browsers? Empirical evidence does not trump
logic. And the line about compromise is another variation on the
"pragmatism" theme. In other words, if you don't understand the
logic, why not "compromise" and use a mystical incantation.

Oh well, it beats this blog from a Dojo fan:-

http://blog.balfes.net/?p=1312

"Even though Dojo does a great job in making cross browser and
platform JavaScript development very easy there are times when you may
want to do something that is specific for a browser. Instead of re-
inventing the wheel you can use the many functions in the Dojo library
to help with this."

Mentions of "re-inventing the wheel" are a virtually infallible
indicator of a neophyte trying to come off as an expert. Of course,
advocating Dojo is a dead giveaway as well.

I've seen Dojo's browser detection code (which they use internally for
virtually everything, including CSS hacks). It's all UA-based, so if
you really want to use browser sniffing, you could do much better than
Dojo's rendition.
 
Reply With Quote
 
 
 
 
Garrett Smith
Guest
Posts: n/a
 
      06-13-2010
On 6/13/2010 2:20 PM, David Mark wrote:
> MS has finally started to recommend feature detection.


[...]

> Another one:-
>
> http://blogs.msdn.com/b/ie/archive/2...-elements.aspx
>
> More jQuery-style object inferences. Lots of valid objections in the
> comments, but diluted by typically clueless "answers" like this one:-
>


[-snip-]

Can you explain what problem is with that feature test? It looks fine to me.

Garrett
 
Reply With Quote
 
 
 
 
David Mark
Guest
Posts: n/a
 
      06-13-2010
On Jun 13, 6:19*pm, Garrett Smith <(E-Mail Removed)> wrote:
> On 6/13/2010 2:20 PM, David Mark wrote:
>
> > MS has finally started to recommend feature detection.

>
> [...]
>
> > Another one:-

>
> >http://blogs.msdn.com/b/ie/archive/2...up-explaining-...

>
> > More jQuery-style object inferences. *Lots of valid objections in the
> > comments, but diluted by typically clueless "answers" like this one:-

>
> [-snip-]
>
> Can you explain what problem is with that feature test? It looks fine to me.


Feature tests are supposed to be as simple and direct as possible.
This one fails on both counts.

var elm = document.createElement("div");
elm.innerHTML = "<foo>test</foo>";


Tangled up with the innerHTML property a la jQuery. That's an
automatic failing grade.


if(elm.childNodes.length !== 1) {


This is an object inference that has nothing to do with what they are
trying to test.


// Enable styling of new HTML5 elements


At this point, they have assumed that any browser that displays the
above quirk can style HTML5 elements.


var elms = [
"abbr","article","aside","audio","canvas","command ",
"datalist","details","figcaption","figure","footer ",
"header","hgroup","mark","meter","nav","output ",
"progress","section","summary","time","video"
];
for(var i = 0; i < elms.length; i++) {


And it's beside the point, but that's just lame.


document.createElement(elms[i]);
}
}

There are plenty of additional indictments (and clueless answers from
the blogger) at the bottom of the cited post.

And the whole idea is ridiculous anyway. You obviously shouldn't use
HTML5 yet. The above magic spell will only help with IE. Who knows
what the other thousand-odd agents out there will do with these
elements?
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      06-14-2010
On 6/13/2010 3:36 PM, David Mark wrote:
> On Jun 13, 6:19 pm, Garrett Smith<(E-Mail Removed)> wrote:
>> On 6/13/2010 2:20 PM, David Mark wrote:
>>
>>> MS has finally started to recommend feature detection.

>>
>> [...]
>>
>>> Another one:-

>>
>>> http://blogs.msdn.com/b/ie/archive/2...up-explaining-...

>>
>>> More jQuery-style object inferences. Lots of valid objections in the
>>> comments, but diluted by typically clueless "answers" like this one:-

>>
>> [-snip-]
>>
>> Can you explain what problem is with that feature test? It looks fine to me.

>
> Feature tests are supposed to be as simple and direct as possible.
> This one fails on both counts.
>
> var elm = document.createElement("div");
> elm.innerHTML = "<foo>test</foo>";
>
>
> Tangled up with the innerHTML property a la jQuery. That's an
> automatic failing grade.
>
>


That would be a different feature test. The given test tests to see what
happens when setting innerHTML.

See the whatwg blog post that JDD linked to describes different in IE
when createElement is used:

http://blog.whatwg.org/supporting-new-elements-in-ie

> And the whole idea is ridiculous anyway. You obviously shouldn't use
> HTML5 yet. The above magic spell will only help with IE. Who knows
> what the other thousand-odd agents out there will do with these
> elements?


If support can be detected and a fallback alternative can be provided,
why not?
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      06-14-2010
On Jun 13, 9:25*pm, Garrett Smith <(E-Mail Removed)> wrote:
> On 6/13/2010 3:36 PM, David Mark wrote:
>
>
>
>
>
> > On Jun 13, 6:19 pm, Garrett Smith<(E-Mail Removed)> *wrote:
> >> On 6/13/2010 2:20 PM, David Mark wrote:

>
> >>> MS has finally started to recommend feature detection.

>
> >> [...]

>
> >>> Another one:-

>
> >>>http://blogs.msdn.com/b/ie/archive/2...up-explaining-....

>
> >>> More jQuery-style object inferences. *Lots of valid objections in the
> >>> comments, but diluted by typically clueless "answers" like this one:-

>
> >> [-snip-]

>
> >> Can you explain what problem is with that feature test? It looks fine to me.

>
> > Feature tests are supposed to be as simple and direct as possible.
> > This one fails on both counts.

>
> > var elm = document.createElement("div");
> > elm.innerHTML = "<foo>test</foo>";

>
> > Tangled up with the innerHTML property a la jQuery. *That's an
> > automatic failing grade.

>
> That would be a different feature test.


That would be a simple and direct feature test that would give a
useful result.

> The given test tests to see what
> happens when setting innerHTML.


Which is inappropriate given the stated goals of the test.

>
> See the whatwg blog post that JDD linked to describes different in IE
> when createElement is used:
>
> http://blog.whatwg.org/supporting-new-elements-in-ie


Rather see my comments at the end of the cited blog. The MS
suggestion is nothing more than an IE-centric object inference.

>
> > And the whole idea is ridiculous anyway. *You obviously shouldn't use
> > HTML5 yet. *The above magic spell will only help with IE. *Who knows
> > what the other thousand-odd agents out there will do with these
> > elements?

>
> If support can be detected and a fallback alternative can be provided,
> why not?


Because you can't do that to any reasonable degree of certainty
(certainly not by following the MS advice).
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      06-14-2010
David Mark wrote:

> Garrett Smith wrote:
>> David Mark wrote:
>> > And the whole idea is ridiculous anyway. You obviously shouldn't use
>> > HTML5 yet. The above magic spell will only help with IE. Who knows
>> > what the other thousand-odd agents out there will do with these
>> > elements?

>>
>> If support can be detected and a fallback alternative can be provided,
>> why not?

>
> Because you can't do that to any reasonable degree of certainty
> (certainly not by following the MS advice).


First of all, I have not read the article. But if, say,
document.createElement("video") returns a reference to an object that has a
play() method, is that not enough indication for you that this element is
supported as suggested by the HTML 5 draft?


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      06-14-2010
On 6/13/2010 6:38 PM, David Mark wrote:
> On Jun 13, 9:25 pm, Garrett Smith<(E-Mail Removed)> wrote:
>> On 6/13/2010 3:36 PM, David Mark wrote:
>>
>>
>>
>>
>>
>>> On Jun 13, 6:19 pm, Garrett Smith<(E-Mail Removed)> wrote:
>>>> On 6/13/2010 2:20 PM, David Mark wrote:

>>
>>>>> MS has finally started to recommend feature detection.


[...]

>>> var elm = document.createElement("div");
>>> elm.innerHTML = "<foo>test</foo>";

>>
>>> Tangled up with the innerHTML property a la jQuery. That's an
>>> automatic failing grade.

>>
>> That would be a different feature test.

>
> That would be a simple and direct feature test that would give a
> useful result.
>
>> The given test tests to see what
>> happens when setting innerHTML.

>
> Which is inappropriate given the stated goals of the test.
>


Goal #2:
| The second is that earlier versions of IE collapse all unknown
| elements at parse time.

>>
>> See the whatwg blog post that JDD linked to describes different in IE
>> when createElement is used:
>>
>> http://blog.whatwg.org/supporting-new-elements-in-ie

>
> Rather see my comments at the end of the cited blog. The MS
> suggestion is nothing more than an IE-centric object inference.
>


They want to know:

| The second is that earlier versions of IE collapse all unknown
| elements at parse time.

- and the test of setting innerHTML should invoke the parser. Inspecting
the result of that shows how the code was parsed.

>>
>>> And the whole idea is ridiculous anyway. You obviously shouldn't use
>>> HTML5 yet. The above magic spell will only help with IE. Who knows
>>> what the other thousand-odd agents out there will do with these
>>> elements?

>>
>> If support can be detected and a fallback alternative can be provided,
>> why not?

>
> Because you can't do that to any reasonable degree of certainty
> (certainly not by following the MS advice).


I Disagree. If the goal is to see what an element can do, that can be
inspected in a test. A test for what a BUTTON's value is, for example
can be to create a button and check its `value` property. Why can't HTML
5 elements be tested using the same approach?

Garrett
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      06-14-2010
On 6/13/2010 6:50 PM, Thomas 'PointedEars' Lahn wrote:
> David Mark wrote:
>
>> Garrett Smith wrote:
>>> David Mark wrote:
>>>> And the whole idea is ridiculous anyway. You obviously shouldn't use
>>>> HTML5 yet. The above magic spell will only help with IE. Who knows
>>>> what the other thousand-odd agents out there will do with these
>>>> elements?
>>>
>>> If support can be detected and a fallback alternative can be provided,
>>> why not?

>>
>> Because you can't do that to any reasonable degree of certainty
>> (certainly not by following the MS advice).

>
> First of all, I have not read the article. But if, say,
> document.createElement("video") returns a reference to an object that has a
> play() method, is that not enough indication for you that this element is
> supported as suggested by the HTML 5 draft?
>


The generalization could be mnde that where the test does that, that
creating a VIDEO element would result in an object with a play method.
It wouldn't detect which file types would be playable, though.

Garrett
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      06-14-2010
On Jun 13, 9:50*pm, Thomas 'PointedEars' Lahn <(E-Mail Removed)>
wrote:
> David Mark wrote:
> > Garrett Smith wrote:
> >> David Mark wrote:
> >> > And the whole idea is ridiculous anyway. *You obviously shouldn't use
> >> > HTML5 yet. *The above magic spell will only help with IE. *Who knows
> >> > what the other thousand-odd agents out there will do with these
> >> > elements?

>
> >> If support can be detected and a fallback alternative can be provided,
> >> why not?

>
> > Because you can't do that to any reasonable degree of certainty
> > (certainly not by following the MS advice).

>
> First of all, I have not read the article. *But if, say,
> document.createElement("video") returns a reference to an object that hasa
> play() method, is that not enough indication for you that this element is
> supported as suggested by the HTML 5 draft?
>


Of course, the operative word is "draft".

And as I have recently written an HTML5 audio add-on to supplant my
old plug-in based audio functions, I can say for sure that the stuff
is not ready. Virtually all of the file formats report that they can
"maybe" work. Virtually none but OGG's work in today's browsers.
It's a shame the browser developers rushed into implementing that
stuff. Their race to be first has resulted in features that are
impossible to test. When and if the features are fixed, we'll still
be left with a slew of iffy browsers.
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      06-14-2010
On Jun 13, 9:59*pm, Garrett Smith <(E-Mail Removed)> wrote:
> On 6/13/2010 6:38 PM, David Mark wrote:
>
> > On Jun 13, 9:25 pm, Garrett Smith<(E-Mail Removed)> *wrote:
> >> On 6/13/2010 3:36 PM, David Mark wrote:

>
> >>> On Jun 13, 6:19 pm, Garrett Smith<(E-Mail Removed)> * *wrote:
> >>>> On 6/13/2010 2:20 PM, David Mark wrote:

>
> >>>>> MS has finally started to recommend feature detection.

>
> [...]
>
>
>
>
>
> >>> var elm = document.createElement("div");
> >>> elm.innerHTML = "<foo>test</foo>";

>
> >>> Tangled up with the innerHTML property a la jQuery. *That's an
> >>> automatic failing grade.

>
> >> That would be a different feature test.

>
> > That would be a simple and direct feature test that would give a
> > useful result.

>
> >> The given test tests to see what
> >> happens when setting innerHTML.

>
> > Which is inappropriate given the stated goals of the test.

>
> Goal #2:
> | The second is that earlier versions of IE collapse all unknown
> | elements at parse time.


That's not a goal, but a description of an unrelated quirk that they
used for their object inference. The only goal is to determine if the
HTML5 elements can be styled.

>
>
>
> >> See the whatwg blog post that JDD linked to describes different in IE
> >> when createElement is used:

>
> >>http://blog.whatwg.org/supporting-new-elements-in-ie

>
> > Rather see my comments at the end of the cited blog. *The MS
> > suggestion is nothing more than an IE-centric object inference.

>
> They want to know:
>
> | The second is that earlier versions of IE collapse all unknown
> | elements at parse time.


For Christ's sake. Again? See above.

>
> - and the test of setting innerHTML should invoke the parser. Inspecting
> the result of that shows how the code was parsed.


They went down the wrong road.

>
>
>
> >>> And the whole idea is ridiculous anyway. *You obviously shouldn't use
> >>> HTML5 yet. *The above magic spell will only help with IE. *Who knows
> >>> what the other thousand-odd agents out there will do with these
> >>> elements?

>
> >> If support can be detected and a fallback alternative can be provided,
> >> why not?

>
> > Because you can't do that to any reasonable degree of certainty
> > (certainly not by following the MS advice).

>
> I Disagree. If the goal is to see what an element can do, that can be
> inspected in a test. A test for what a BUTTON's value is, for example
> can be to create a button and check its `value` property. Why can't HTML
> 5 elements be tested using the same approach?
>


For one, HTML5 isn't even finished yet. For two, see my response to
PE regarding such detection. It's a complete waste of time at the
moment (and likely will be for years to come).
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Best Buy Recommends Blu-Ray Over HD DVD Tarkus DVD Video 7 02-13-2008 04:10 AM
Printer recommends? Crash Gordon Digital Photography 6 02-13-2006 05:22 PM
Microsoft recommends Crippling IE to protect your PC JedMeister NZ Computing 4 09-02-2004 02:52 AM
Homeland Security Agency recommends abandoning IE dotnetforfood ASP .Net 3 07-04-2004 07:03 PM
Holey Moley! Micro$oft Recommends Linux? --= ֧m K0 =-- Computer Security 19 01-12-2004 07:54 PM



Advertisments