Prev: Note 1. ECMAScript. Bound functions.
Next: Thoughts on JS library to help with event driven paradigms
From: David Mark on 13 Jun 2010 17:20
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/2010/06/10/same-markup-explaining-quot-jscript-version-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.
From: Garrett Smith on 13 Jun 2010 18:19
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-quot-jscript-version-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
From: David Mark on 13 Jun 2010 18:36
On Jun 13, 6:19 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> 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/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[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?
From: Garrett Smith on 13 Jun 2010 21:25
On 6/13/2010 3:36 PM, David Mark wrote:
> On Jun 13, 6:19 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> 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/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?
From: David Mark on 13 Jun 2010 21:38
On Jun 13, 9:25 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> On 6/13/2010 3:36 PM, David Mark wrote:
>
>
>
>
>
> > On Jun 13, 6:19 pm, Garrett Smith<dhtmlkitc...(a)gmail.com>  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/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.

>
> > 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).
 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Note 1. ECMAScript. Bound functions.
Next: Thoughts on JS library to help with event driven paradigms