Thursday, January 29th, 2009

IE=’\v’==’v’

Category: Tip

>pre>

That is the current winner in the shortest way to test for IE (including 8). The other notable was:

javascript
< view plain text >
  1. IE=top.execScript?1:0

Huh :)

Gareth Heyes (the chap who did the v trick) has posted on this himself and comes up with One Line To Rule Them All:

javascript
< view plain text >
  1. B=(function x(){})[-5]=='x'?'FF3':(function x(){})[-6]=='x'?'FF2':/a/[-1]=='a'?'FF':'\v'=='v'?'IE':/a/.__proto__=='//'?'Saf':/s/.test(/a/.toString)?'Chr':/^function \(/.test([].sort)?'Op':'Unknown'

Posted by Dion Almaer at 1:02 am
20 Comments

++++-
4.4 rating from 53 votes

20 Comments »

Comments feed TrackBack URI

The first is a very nice application of “JScript Deviations from ES3″ §7.2.

Quote:
JScript does not support the \v vertical tab character as a white space character. It treats \v as v.

(Google if you never seen that document)

Comment by leonyu — January 29, 2009

Both of these should be considered ‘hacks’.

They take a behaviour or method that (currently) makes IE unique, and decide that “this MUST be IE”.

This is like saying “If it’s round and shiny, it MUST be a CD”.

The behaviour that makes IE unique here may not always be unique to IE. For example, ‘document.all’ used to be used to detect IE, but then it was adopted by other browsers such as Opera, breaking this assumption.

Jake.

Comment by jaffathecake — January 29, 2009

As leonyu pointed out, I would not use that one… no one knows when other browsers may change their behavior.

I still prefer this one:
IE=/*@cc_on!@*/!1

It’s so mysterious!

Comment by fredck — January 29, 2009

It’s far better to use feature detection instead of browser sniffing.

Comment by stepanvr — January 29, 2009

i prefer `$.browser.msie` over `’v'==’v'`. true, that’s 14bytes instead of 9bytes, but you only ever have to write it once; true, it needs jQuery to be loaded beforehand—but then again, given the state of affairs, what you can do (reliably) in javascript (and keep sane) in case you forsake jQuery (or another capable library) (especially if `’v'==’v'` should return true) is, erm, pretty much zilch.
.
@jaffathecake “”"The behaviour that makes IE unique here may not always be unique to IE [...] This is like saying “If it’s round and shiny, it MUST be a CD”.”"”—you’re absolutely right in principle here. BUT: your cd example does start to work if you know (98% of) your clients will ever only come up with one of the following: a cd, a sponge, a screwdriver. and yes, `’v'==’v'` MAY fail anytime without warning, but it very probably won’t within the next few years. i am not sure how jQuery does its browser detection (which is now considered deprecated btw), all i am sure of is that it WILL fail in ten years from now, if not earlier, and that it CAN fail anytime a client is misconfigured (afaik opera was the first browser to bring referer spoofing to a broader audience—it made it very easy for users to announce itself as msie).

Comment by loveencounterflow — January 29, 2009

rejoice my brethren and let us go on forever to marvel at the miraculous achievements of the one big machine that we worship as the inter of nets, and let us together harken to the gospel, and the wisdom in it.
.
yes it is true that some guys over at ttp://css-tricks.com/browser-detection-is-bad/
seek to put forth a view that abstains from sniffing the client. and mean to do feature sniffing instead. wide is the sea and innumerable are the ways to reach the other side indeed.
.
but the true tale of how it came about, how technological evolution in its unfathomable crowdy wisdom has managed to bring upon us the clear light of the user agent string, that unique piece of techno poetry—that tale has been told by a man called aaron, and he wrote it down in his blog, and we shall have nought to add to his words: http://webaim.org/blog/user-agent-string-history/

Comment by loveencounterflow — January 29, 2009

Whatever happened to “Premature optimization is the root of all evil”?

Comment by LeoHorie — January 29, 2009

Who has ever used a vertical tab anyway? I did’nt in 30 years.

Comment by Aimos — January 29, 2009

@loveencounterflow

$.browser has been deprecated and is no longer used within the jQuery library. jQuery now uses feature detection (via $.supports). The reasoner the browser property remains is so 3rd party scripts have time to remove it from their code.

also if you look closer i would say the “var IE = ‘\v’==’v”” might work better than “$.browser.msie = /msie/.test( userAgent ) && !/opera/.test( userAgent )” because its latter is just doing a quick test of the UA string.

Comment by howardrauscher — January 29, 2009

Actually, I think the UA string is more reliable here. The purpose of the UA string is to identify the user agent, on purpose. Whereas it’s just coincidence that the vertical tab thing identifies IE.
.
The UA is sometimes spoofed, yes, but there the browser is actively lying about what it is. Whereas with the /v behaviour, that could appear in non-ie browsers by accident, or be fixed in IE.

Comment by jaffathecake — January 29, 2009

>>It’s far better to use feature detection instead of browser sniffing.
.
Seems like this is more like feature detection than browser sniffing.
.
Frankly, neither is perfect. It’s completely possible that future browsers will break current methods of feature detection. All it takes is yet another case where a feature exists but is buggy to screw everything up.
.
My theory is that the only safety comes in numbers. If enough sites use a library, it’s the browser’s job to be compatible. If there are thousands of sites out there using jQuery, and a new version of a browser breaks something, it’ll be seen as a buggy browser.

Comment by Nosredna — January 29, 2009

I work on a website with 50,000+ active customers and we were formerly using IE conditional comments alone to differentiate between users with IE6 and those with IE7. We began receiving reports from users with IE7 of unusal behavior (select boxes disappearing and hover effects not working). Upon further investigation, we discovered these users possessed a user agent string that contained *both* “IE6″ and “IE7″ in it. Even stranger, although their browsers were IE7, they identified themselves as IE6 according to the conditional comments. After speaking with these customers and with Microsoft, we were not able to determine exactly how they screwed up their browsers.

You can simulate this issue for yourself by using the .reg files on this website to change your user agent:
http://www.fiddlertool.com/ua.aspx

Since this issue affected a significant enough number of our customers, we began using object detection *and* conditional comments to differentiate between IE6 and IE7. I’ll paste this below in case someone else may benefit from it:

var isMSIE7 = true;

var isMSIE6 = true;
if( typeof window.XMLHttpRequest != ‘undefined’ ) {
//Fix the browser detect for when IE7 falsely reports itself as IE6
var isMSIE7 = true;
isMSIE6 = undefined;
}

Comment by drlongghost — January 29, 2009

Trying again to get my code past the filter as semi-intelligible:

var isMSIE7 = true;

var isMSIE6 = true;
if( typeof window.XMLHttpRequest != ‘undefined’ ) {
//Fix the browser detect for when IE7 falsely reports itself as IE6
var isMSIE7 = true;
isMSIE6 = undefined;
}

Comment by drlongghost — January 29, 2009

oh well…. there’s conditional comments in there that are being stripped out by ajaxian…

Comment by drlongghost — January 29, 2009

IE=top.execScript?1:0
should be
IE=!!top.execScript
.
I would have a hard time trusting many of these. The odds of them colliding in existing browsers (eg Gecko- and Webkit-based minority browsers, particularly if they’re off the release cycles of Firefox and Safari. The “one” line check for Chrome particularly heightens that worry for me. At some time, a current version of Safari and Chrome ought to correctly identify as both Safari and Chrome within any given feature sniffer.

Comment by eyelidlessness — January 29, 2009

given IE’s historical hackiness, I’m inclined to “trust” a hack like this similar to how I have trusted other types of IE-specific hacks (like the onscroll domready test hack, for instance) for IE only.
.
But that one-line-to-rule-them-all goes too far IMHO. That’s an awful lot of hackiness surrounding all these wonderful browsers which are (as opposed to previous versions of IE) auspiciously trying to be “standards compliant”. In those cases, relying on hacks is ASKING for trouble because the party-line should likely be “once we find a bug/hack, we should fix it asap”.

Comment by shadedecho — January 30, 2009

>>relying on hacks is ASKING for trouble because the party-line should likely be “once we find a bug/hack, we should fix it asap”.
.
Problem is we have IE6s around from the dawn of time, some of them even unpatched with the JavaScript memory leak fix. If all of the browsers autppatched, we could write to the standard and the browser bugs would get fixed.
.
By the way, I’m amazed at Google’s balls. They update the browser silently! I’m not even sure how to get older versions to test against, not that Chrome has had enough share for me to worry about yet.

Comment by Nosredna — January 30, 2009

“By the way, I’m amazed at Google’s balls. They update the browser silently! I’m not even sure how to get older versions to test against, not that Chrome has had enough share for me to worry about yet.”
.
Which is great. If they’re on the tubes, they’re up to date. If they’re not, they’re not using your app, right?

Comment by eyelidlessness — January 30, 2009

FYI, Chrome lies about its user agent a hrf=”http://lifehacker.com/5142420/google-chrome-accesses-hotmail-by-pretending-its-safari”>now.

Comment by TNO — January 31, 2009

we’ve got another winner, summarized in the updated blog entry as:

!+”\v1″ // true only in IE

have fun with unstandard behaviors ;-)

Comment by WebReflection — January 31, 2009

Leave a comment

You must be logged in to post a comment.