MS recommends "feature detection"

[David Mark]

MS has finally started to recommend feature detection.

http://blogs.msdn.com/b/ie/archive/2010/04/14/same-markup-writing-cross-browser-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/...sion-quot-and-styling-new-html5-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.

 

[Garrett Smith]

MS has finally started to recommend feature detection.
[...]

Another one:-

http://blogs.msdn.com/b/ie/archive/...sion-quot-and-styling-new-html5-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

 

[David Mark]

MS has finally started to recommend feature detection.
[...]

Another one:-

http://blogs.msdn.com/b/ie/archive/2010/06/10/same-markup-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);
}
}

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?

 

[Garrett Smith]

MS has finally started to recommend feature detection.
[...]

Another one:-

http://blogs.msdn.com/b/ie/archive/2010/06/10/same-markup-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?

 

[David Mark]

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/2010/06/10/same-markup-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.

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

 

[Thomas 'PointedEars' Lahn]

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

 

[Garrett Smith]

[...]

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.

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.

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

 

[Garrett Smith]

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

 

[David Mark]

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.

 

[David Mark]

On 6/13/2010 3:36 PM, David Mark 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.

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.

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.

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

 

[David Mark]

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.

Neither does the AUDIO element, which is detectable but thoroughly
worthless at the moment. Less than worthless really as it is flying
false flags in many cases.

 

[Garrett Smith]

[...]


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

Well CSS2.1 is not finished either.

HTML 5 is different in a few ways. Some HTML 5 features codify existing
browser behavior. They take things that work and put them into the spec.

Codified features start with the doctype and include things like
navigator.userAgent and the input.width property, both discussed
recently, plus others, such as javascript: pseudo-protocol.

Some codified features, such as document.all and a FORM's "past names
map", are inconsistent, badly designed, and have never worked right.
Specifying them won't make them any more advisable or well-designed. If
and when these features reach TR status, they may have the potential to
teach them to a developer who is unaware of their history and
programming "by the book". Such developer relying on the standard
feature may not immediately notice the problems. It seems as if these
features were specified to cater to implementors, not to the developer
who reads specifications.

Ian Hickson:
"I think it is woefully optimistic to expect any significant number of
authors to read the specification."
http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0512.html

The sad thing about that is that it is probably right. So few actually
the specifications these days. When I was learning this stuff, things
like jQuery and Prototype would not have been possible. Even if the APIs
ahd been in place at that time, the performance in the browsers could
never have handled such inefficient style of coding and the file sizes
would not have been practical. The closest thing to those was Dan
Steinmann's Dynamic Duo. And in those days, standards and specifications
were something to be hoped for. Then came the DOM core and DOM 2 HTML
specs. Not without their problems, but in contrast to what was
available, miles ahead.

Dynamic Duo worked in IE4 and Netscape 4. Back then, you *couldn't*
write same code paths and expect it to run in both browsers. Not even
for image swaps because in NS4, if the image was inside of a positioned
thing, that thing became a layer and so the image was not a property of
the document, but a property of the containing layer's document
property. To swap an image required a depth-first traversal. That is
something that the previous FAQ notes explained. Still there, but not
linked any more. Interesting history lesson, and the relevance it bears
is that today, the libraries are larger than DynLayer API, yet they have
much fewer browser differences to contend with (no depth first traversal
needed for chaging an image swap). So, it is a pity that today, it is
almost a given that developers won't read the specs.

Going back to HTML 5 specifying input's width, it is not actually a new
feature but it is a new standard. The design of HTML 4 specified an
INPUT's *size* attribute as "the width of the element in pixels" for
input type="image", otherwise, for text or password inputs, the number
of characters. The feature is overloaded to do two different things and
it never worked right for character width; browsers always seemed o vary
on how wide the element would be and size="4" would not necessarily
correspond to CSS width: 4em. It turns out browsers recognize `width`
and `height` and treat it as such for certain input elemnets, so now
HTML 5 specifies a `width` attribute on INPUT type="button" and
type="image". It works as specified, though not exactly so in IE, as
shown in the recent "jquery quiz".

Another difference with HTML 5 is that it is modular. There are parts of
the specification that are further along than others. There exists the
possibility that some of it will be scaled back.

New HTML 5 features are a different story. Any new feature must be
carefully evaluated and tested and fallback handling and degradation
strategies should be considered in the initial program design.

Garrett

 

[Garrett Smith]

[...]

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.

I think it would be helpful to the implementors to briefly elaborate on
that and provide a few test cases. It would be an eye opener and a wake
up to them. I'm always annoyed when I get a new standard feature, RTM,
and find out that they implemented it wrong.

Garrett

 

[Justin Johnson]

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.

That's unfortunate, especially when their own article on the subject
promotes the opposite right off the bat.

http://dojotoolkit.org/reference-guide/quickstart/browser-sniffing.html

"You should try to use capability detection (http://dev.opera.com/
articles/view/using-capability-detection/) when possible. When that is
not an option, Dojo provides a number of is variables for browser
detection, defined at runtime based on the users current browser."

 

[David Mark]

That's unfortunate, especially when their own article on the subject
promotes the opposite right off the bat.

http://dojotoolkit.org/reference-guide/quickstart/browser-sniffing.html

"You should try to use capability detection (http://dev.opera.com/
articles/view/using-capability-detection/) when possible. When that is
not an option, Dojo provides a number of is variables for browser
detection, defined at runtime based on the users current browser."

Yeah, lip service. They put that up fairly recently I think. For the
longest time, their authors advocated sniffing the UA string as more
"pragmatic" and "faster" than feature detection.

They have so much of it that there is very little hope of every
cleaning it up. The typical widget is crawling with isIE checks (and
still doesn't support Opera!) And when IE8 came out, they added lots
of isIE8 checks (to go with the existing isIE6 and isIE7 checks). No
wonder they are so anxious to wish IE6/7 out of existence.

And, of course, the previous version of Dojo (1.3) didn't work with
IE8. They told their users that 1.3 never claimed to work with IE8.
(!) I'm sure they'll say the same thing about 1.4 and IE9 (assuming
they have any users left at that point).

 

[David Mark]

David Mark wrote:
Garrett Smith wrote:
David Mark wrote:

[...]

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.

I think it would be helpful to the implementors to briefly elaborate on
that and provide a few test cases.

Well, first off, the answer "maybe" is useless. What the hell is the
calling app supposed to do with that?

My current audio module will return true or false for browsers that
use plug-ins. That allows for it to make an informed choice when
presented with multiple alternative formats.

The HTML5 implementations that I tested (e.g. latest Opera, Safari
Chrome, FF). failed to play most of the formats that were detected as
maybes. IIRC, Chrome was the best performer. The rest played only
OGG's, failing silently on the rest.

It would be an eye opener and a wake
up to them.

They are past the point of no return. If and when they fix the issue,
it won't affect the versions that I tested.

I'm always annoyed when I get a new standard feature, RTM,
and find out that they implemented it wrong.

Doesn't really bother me as HTML5 is not a standard yet and won't be
viable on the Web until years after it becomes one. Bits of it may be
usable right away. For example, if all of your audio is in OGG format
and you only "care about" a handful of the latest browsers, you can
assume the "maybes" are positive results and get away with it. But as
the general public doesn't care what developers profess to care about,
it doesn't make sense to me to switch any time soon.

I'll post the HTML5 audio add-on when I get a chance and it will
include disclaimers that indicate it is a downgrade for most
contexts. BGSOUND's for IE and plug-ins for the rest (as implemented
in my current audio API) has worked well for me for over a decade and
that strategy will likely continue to work in the future. Granted,
loading a plug-in is not the snappiest of operations (and can have
adverse effects), which is why I wanted to leverage HTML5 when
possible. The only other alternatives are Flash and Java applets,
both of which I detest.

 

[Garrett Smith]

On Jun 13, 9:50 pm, Thomas 'PointedEars' Lahn<[email protected]>
wrote:
David Mark wrote:
Garrett Smith wrote:
David Mark wrote:
[...]

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.

I think it would be helpful to the implementors to briefly elaborate on
that and provide a few test cases.

Well, first off, the answer "maybe" is useless. What the hell is the
calling app supposed to do with that?

Maybe? What do you mean?

Doesn't really bother me as HTML5 is not a standard yet and won't be
viable on the Web until years after it becomes one. Bits of it may be
usable right away. For example, if all of your audio is in OGG format
and you only "care about" a handful of the latest browsers, you can
assume the "maybes" are positive results and get away with it. But as
the general public doesn't care what developers profess to care about,
it doesn't make sense to me to switch any time soon.

HTML 5 is a draft standard. It is being implemented now. Fallbacks that
you've described using BGSOUND can be used when the feature can be
detected.

I've not used the AUDIO or VIDEO elements at all. SWFObject us awful
code and has been shown here to not work well in versions of IE.

Then there are those who prefer using the approach on Adobe for Flash
detection.

[...]

Garrett

 

[David Mark]

On 6/13/2010 7:11 PM, David Mark wrote:
On Jun 13, 9:50 pm, Thomas 'PointedEars' Lahn<[email protected]>
wrote:
David Mark wrote:
Garrett Smith wrote:
David Mark wrote:
[...]
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.
I think it would be helpful to the implementors to briefly elaborate on
that and provide a few test cases.

Well, first off, the answer "maybe" is useless.  What the hell is the
calling app supposed to do with that?

Maybe? What do you mean?

RTFM. I would link to it if their miserable draft documents didn't
lock up my browser every time I try to read them.

HTML 5 is a draft standard. It is being implemented now. Fallbacks that
you've described using BGSOUND can be used when the feature can be
detected.

Did you read my post? You can't infer anything from the ridiculous
"maybe" or "probably" results. As the names might indicate, they are
ambiguous. So, as of right now, trying to detect the features that
matter (e.g. what formats are supported) is impossible.

I've not used the AUDIO or VIDEO elements at all.
Clearly.

SWFObject us awful
code and has been shown here to not work well in versions of IE.

Yes, it is, and always has been, complete trash. Last I checked, it
was crawling with browser sniffs, ironically many of them for IE.

Then there are those who prefer using the approach on Adobe for Flash
detection.

Yes, their own rendition makes SWFObject look masterful. If you want
Flash, use My Library. AFAIK, it's the only implementation out there
that refrains from browser sniffing. Works in every browser/Flash
combination I've ever tried, in both HTML and XHTML DOM's, dating back
to the turn of the century. Was pleased to see it is still working in
IE9. And I have every reason to believe it will continue to work
indefinitely. Haven't even looked at the code in years either.

Why a giant concern like Adobe would continue to ship inept deployment
code for such a key product is beyond me. Of course, Apple builds
mobile sites with SproutCore and MS promotes jQuery. Funny old world.

 

[Garrett Smith]

On 6/13/2010 7:11 PM, David Mark wrote:

On Jun 13, 9:50 pm, Thomas 'PointedEars' Lahn<[email protected]>
wrote:
David Mark wrote:
Garrett Smith wrote:
David Mark wrote:

[...]

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.

I think it would be helpful to the implementors to briefly elaborate on
that and provide a few test cases.

Well, first off, the answer "maybe" is useless. What the hell is the
calling app supposed to do with that?

Maybe? What do you mean?

RTFM. I would link to it if their miserable draft documents didn't
lock up my browser every time I try to read them.

The one-page freezes the browser. It's a good example of why not to
traverse the DOM on page load. Instead, either link to the correct page
of the multipage or link to the one on w3.org.

I'm not that motivated to do research on audio now.

Garrett

 

[David Mark]

On 6/14/2010 5:09 PM, David Mark wrote:
On 6/13/2010 7:11 PM, David Mark wrote:
On Jun 13, 9:50 pm, Thomas 'PointedEars' Lahn<[email protected]>
wrote:
David Mark wrote:
Garrett Smith wrote:
David Mark wrote:
[...]
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 theycan
"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.
I think it would be helpful to the implementors to briefly elaborateon
that and provide a few test cases.
Well, first off, the answer "maybe" is useless.  What the hell is the
calling app supposed to do with that?
Maybe? What do you mean?

RTFM.  I would link to it if their miserable draft documents didn't
lock up my browser every time I try to read them.

The one-page freezes the browser. It's a good example of why not to
traverse the DOM on page load. Instead, either link to the correct page
of the multipage or link to the one on w3.org.

Even after disabling JS it was an unbelievable dog.

I'm not that motivated to do research on audio now.

You shouldn't need any links to find out how the HTML5 AUDIO DOM
bindings are supposed to work. And it shouldn't take thirty seconds
with a few of the latest browsers to find out that they don't work in
any useful way at this time. Just Google based on the information I
gave you. Until then, I guess you'll have to take my word for it that
it is useless.