Thursday, January 29th, 2009
IE=’\v’==’v’
JAVASCRIPT:
-
-
IE='\v'=='v'
-
That is the current winner in the shortest way to test for IE (including 8). The other notable was:
JAVASCRIPT:
-
-
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:
-
-
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'
-
4.4 rating from 52 votes
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)
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.
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!
It’s far better to use feature detection instead of browser sniffing.
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).
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/
Whatever happened to “Premature optimization is the root of all evil”?
Who has ever used a vertical tab anyway? I did’nt in 30 years.
@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.
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.
>>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.
Why are people imagining these fringe case scenario’s? There are a handful of browsers you focus on and develop for. If the browser in question has less than a 1% usage share you don’t bother and hope for the best. A UA string is commonly spoofed for one reason or another. Instead of asking a browser what it calls itself, duck typing it is a much more reliable route.
.
The above method for IE detection is old as dirt, and I’m surprised its coming up now. All those complaining about it being a hack should take a step back and look at the realistic utility. Sometimes nothing beats a good hack.
.
“…blah blah blah….future browsers….blah blah blah…”
.
Future compatibility is never a guarantee, just a hope. Microsoft will fix this bug in time, of that I have confidence (Promising ES3.1 compliance), and if that means a movement more towards standards then it may be irrelevant if the above test returns false for IE. Otherwise by the time a browser comes along hat fails this test, you probably need to test the code in that browser anyway (once it gains significant market share). Of course you could use a conditional compilation comment as shown earlier, but just like this, you assume that feature will be supported in the future as well, and not adopted by a competitor. (Imagine a scenario where Maxthon steals the JScript engine and the Gecko rendering engine, which isn’t a too unlikely scenario)
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;
}
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;
}
oh well…. there’s conditional comments in there that are being stripped out by ajaxian…
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.
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”.
>>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.
“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?
FYI, Chrome lies about its user agent a hrf=”http://lifehacker.com/5142420/google-chrome-accesses-hotmail-by-pretending-its-safari”>now.
post fail..
link
we’ve got another winner, summarized in the updated blog entry as:
!+”\v1″ // true only in IE
have fun with unstandard behaviors ;-)
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.
oldtimerock from lose 5 pounds a week