During my Ajax Experience session I talked about browser detects and how almost nobody knows how to do them right. I’d like to repeat the main outline of my solution here.
I’d also like to ask you to participate in a little research project by spending two minutes of your time on checking whether your stat package or farm reports any Google Chrome hit. It should, by now. If it doesn’t, it’s likely broken or badly maintained.
This little test will allow us to distinguish between good and bad stat packages/farms.
Please participate. It takes about two minutes. Thanks.
In order to write a good browser detect, you should use
navigator.userAgent only as a last resort. The problem with this property is that browsers (especially the minor ones) habitually lie about their identity in order to bypass browser detects written by clueless web developers.
Take the following string. Can you identify the browser?
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en)
If you guessed IE6, you’re wrong. It’s Opera 9.26 masquerading as IE6. (It could easily be Safari, too.)
In other words, a purely
navigator.userAgent-based browser detect will identify many minor browsers as IE. How many? Nobody knows, because all browser detects out there are broken.
Anyway, that’s the reason I propose a three-tiered approach:
window.opera. (If you know of more, please leave a comment.)
navigator.vendor. Not all browsers support it, but the browsers that do all speak the truth — for now. As far as I know Safari, Chrome and Konqueror support this property, while in Firefox the property exists but is empty (in other words: useless).
navigator.vendor, too, some all-too-bright web developer will hit on the luminous idea to use this property for denying certain browsers access to his site. Then, all minor browsers will be forced to start lying about their identity once more and will give
Microsoft. The property will become useless overnight.
navigator.userAgentonly when the two previous methods fail. If you’re forced to do this, the basic trick is to detect minor browsers first. For instance, take this browser string:
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 9.26By now you can probably guess that this is Opera 9.26 (this time identifying itself as IE instead of masquerading). However, if you start your
navigator.userAgent-based browser detect by detecting IE you’ll interpret this string incorrectly.
My browser detect script more or less implements this three-tiered approach (though it doesn’t use conditional comments yet because frankly I thought of that only a few days ago).
All this begs the question: how reliable are the commercial stat packages and farms out there? I wouldn’t be in the least surprised if they are totally unreliable because they wrote their browser detects ages ago and never updated them because they don’t follow the browser market and/or don’t know what they’re doing at all.
Fortunately, right now (and I mean right now) we’re in a unique position to test them and see how badly (or well) they perform by checking one simple criterion.
A properly maintained stat package or farm will report some Google Chrome hits by now.
Sure, Google Chrome has a tiny market share (I heard somebody say 0.77% at the conference, but have no way of checking this number, so feel free to disbelieve it).
But if you’ve got a site even marginally related to web development you can be sure that somebody out there looked at it in Chrome, even if only to leave a snarky comment about something not working properly.
In other words, I believe that most sites out there have received at least one hit by Chrome by now. If that hit is not reported, your stat package or farm is just not paying attention to anything.
I’m kind of expecting Google Analytics, at least, to properly report Google Chrome, but I’d love to be reassured in that respect.
So I’d like to ask you all to do the following:
Nedstat, possibly the oldest stat farm in the world and the one that I use, fails miserably. So does thecounter.com, which I use for getting huge aggregate numbers.
Thanks for cooperating in this research project.
Upcoming speaking gigs:
Comments are closed.