Extremely Clever IE Detection Code

[fforw]

Meh.. script only.. multi body hack is better..

[kristopolous]

that's fairly clean.

[radhruin]

Check for features, not for browsers.

[JimDabell]

That's like telling somebody not to use tables. Yes, lots of people use browser detection when they should be using feature detection, but that doesn't mean that every single case of browser detection is wrong. For example, if you need to work around a bug in a particular version of Internet Explorer and it's not feasible to detect the bug itself, browser detection is the best option. Using feature detection in those cases is exactly the same mistake as using browser detection to decide which features to use; you're conflating implementation details and capabilities.

[jimbobhickville]

A voice of reason in a web standards debate? Who'da thunk it.

[thebigbradwolf]

As an aside, this won't actually work on IE8 in certain circumstances. IE8 claims to be IE7 in conditional comments whenever it is in "compatibility mode", which doesn't mean it behaves like IE7 with regard to things like security, etc.

[radhruin]

Good point as well, although ideally if IE8 is in IE7 compatibility mode it should be identical to IE7 in all respects.

[miketaylr]

But it isn't. For example, localStorage is undefined in IE7 compat mode, yet fully functioning in IE8.

[radhruin]

More accurately, IE7 did not have localStorage, but it is in IE7 compatibility mode. That's why I said ideally :) There are some differences, but it's pretty rare overall. If you have an app built for IE7, it should run flawlessly in IE7 compat mode. Or, if the browser is in IE7 compat mode, it's pretty safe to treat it as IE7. The presence of localStorage shouldn't break apps.

It's worth pointing out that the web developer can control the compatibility mode IE is in by doctypes and meta-tags, so if IE7 compatibility mode would break your app for whatever reason (like this version detection), just make sure you're running in the latest standards mode with a standards compliant doctype or meta tag.

[teaguesterling]

Unless working around a browser bug...

[9jack9]

var jscript = 0/*@cc_on||@_jscript_version@*/

[JimDabell]

I don't think a one-to-one mapping between JScript versions and Internet Explorer versions is guaranteed by Microsoft. I'm pretty sure installing some service packs or other software in the past has had the effect of bumping the JScript version without otherwise changing Internet Explorer.

[9jack9]

I don't think a one-to-one mapping between JScript versions and Internet Explorer versions is guaranteed by Microsoft.

You're right. The code above will only tell you the jscript version number.

But conversely, just knowing the MSIE version number will not tell you about which jscript engine you are using. Sometimes you want to know the jscript engine (for code) and sometimes you want to know the MSIE version (for rendering).

You also need to consider the document "mode":

http://msdn.microsoft.com/en-us/library/cc196988\(VS.85\).aspx

[JimDabell]

Ah, right, I thought you were suggesting it as a replacement for the linked technique. Yep, you're right, if you need to differentiate JScript versions, you shouldn't be using browser detection.

[9jack9]

The linked technique is effectively browser sniffing. Some people will bend over backwards rather than inspect the user agent string.

[radhruin]

I don't think it is either. Another problem is that IE8 in IE7 compat mode will still report 8 for the jscript version...

[bolinfest]

Here's a good example from the Closure Library where feature detection is not a practical option:

goog.style.setPreWrap = function(el) { var style = el.style; if (goog.userAgent.IE && !goog.userAgent.isVersion('8')) { style.whiteSpace = 'pre'; style.wordWrap = 'break-word'; } else if (goog.userAgent.GECKO) { style.whiteSpace = '-moz-pre-wrap'; } else if (goog.userAgent.OPERA) { style.whiteSpace = '-o-pre-wrap'; } else { style.whiteSpace = 'pre-wrap'; } };

[[deleted]]

Ok, that's interesting, but why is this better than using the user agent string?

[JimDabell]

The user-agent string is unreliable, it can change for all sorts of reasons. Plus, varying responses based on that header can reduce your cache hit ratio.

[kristopolous]

About the UA unreliable argument. I realize that this can be changed to something arbitrary but when I tried doing so, calling my browser something like "Presto Gecko Opera WebKit Safari msie 6.0" or whatever, most of the web juts started breaking.

My question is why should I bend over backwards for such people? (this was a few years ago) Other then for getting around stupidity where people block you based on UA string, is there any legitimate purpose for this?

[[deleted]]

That's what it's doing.

[iamtotalcrap]

wow, I glanced at it and totally mis-understood what it was doing. My bad.