And here is why:
It is against the spirit of web standards
The whole reason that web standards exist is so that we don't have to write specific code for specific environments. We should write code that adheres to established standards and software in charge of displaying our code should display it as the standards dictate.
It relies on the browser user-agent string
... which has a hilariously disastrous history and is easily spoofable.
It can hinder devices
Example: you detect for the iPhone and serve is special content. Now the iPhone can never see the web page as other browsers see it, despite it being fully capable of doing so.
So why do we do it?
We do it because different browsers handle things differently and browser detection can get us out of a pinch and get things working how they should. You can hardly blame us right?
Often the situations leading up to us resorting to browser-detection are rage-inducing. But remember it's often not the browser that is at fault. Even in the case of IE 6, it was the most standards-compliant and advanced browser of it's time when it was released. And some of the standards that we have today were not complete at that time.
What should we do instead?
I'm the first to admit that real-world web design sometimes needs quick fixes, budget-acceptable solutions, and making damn sure features work as intended. This doesn't always allow for altruistic choices that leave out some functionality because it is the "right thing to do."
Ideally...
... we would do capability testing. That's the information we really need right? Test if the environment we are in is capable of what we want to do. If it is, do it. Easier said than done, I'm sure, and myself I'd hardly know where to begin. But I'm sure some of ya'll are very smart folks and can get it done (or are already doing it!)
More
Here is a bit about capability testing from Quirksmode. And here is Dave Shea with a good example of why browser detection ain't good.
Chris,
Are you for or against browser detection to serve up different style sheets?
For example: I currently use an HTC Wizard (O2 Xda Mini II S) and some sites (even those with a mobile style sheet) look abysmal due to resized graphics, fixed sizes that are too wide for the screen etc.
I would personally prefer to detect the UA of mobile devices and provide a different style sheet for large screen mobiles (Win Mobile devices, LG Viewty) and smaller screen mobiles (Sony Erricsson C905).
Just my 2 cents
Chris
I don’t use browser detection for that, but screen-width detection. I start with the stylesheet appropiate for a skinny screen and then use js to detect the width and change the stylesheet if required.
Then why do yo use
<!--[if IE 6]>...<![endif]-->and<!--[if IE 7]>...<![endif]-->?I’d rather do:
ha!
:)
Yeah, that’s much more nice. But since we can’t do things this way browser detection is the only way out.
right click, view source
Conditional comments are only executed by IE, all other browsers treat them as any other comment. So using them at all is implying IE. In this way they are also an implied capability detection : note that they are nested in a comment tag. This is similar to (but not exactly) saying
When we normally do capability detection, there are some techniques that inadvertently can identify the browser such as checking for event listeners. Here we are just taking advantage of the fact that if this conditional executes, then the browser is IE. The browser detection Chris is writing about is done with javascript and using built in methods that are insufficient at actually detecting the client identity. And, those methods require that future changes in the browser mean a complete rewrite of the code. Capability detection allows for future standards compliance in a browser that lacks it today. With conditional comments we can also easily replace a link to a css file, or js file or what have you. So while you have a point that CC’s are detecting a browser, their use is a much lesser evil than using traditional browser detecting methods.
Post Title is too generous. You can use browser detection to improve user’s interaction with your site.
Simple example. If I have file-upload input on the page, It would be great for user to know that he can drag and drop files on the input. But this is only Chrome and Safari feature. So, I have to user browser detection or browser-specific css-hacks.
Exactly the point, wouldn’t it be better to detect if the browser was capable of drag and drop instead of for the browser itself? That way when a new browser that comes out supports it, you are already good to go.
I don’t really agree with the title of the post, but I do see Chris’ point. Browser detection and manipulating a user agent string does have it’s upside to things I.E. detecting cloaking and other mischievous acts on the internet. :)
User agent detection is bad. Feature-based detection is good.
That sums it up pretty well, David. I completely agree.
Well said! I think this is what the title should read :)
Thats really should be the title of the post!
I also think I see the point here, but at this point I still want some sites to give me that streamlined mobile site if it’s available. Maybe a site like Twitter is doing it right when they default the mobile site for phones, but give the option for standard view… Better yet, a site could remember a user’s preference and give each what s/he wanted.
I think I understand what you are trying to say and I would agree with you for the most part. I do however believe that the internet is there to access information in the best way possible. I do believe that the right solution for one device is not necessarily the right solution for another device. For example, iPhone vs a wide screen monitor. A site that does this is Amazon. When you first go to the site on the iPhone it takes you to the iPhone page with an option to go to the “PC” page. So I do believe that a capability testing is a great solution as well as device detection. That is just my humble opinion though.
…is bad, and inevitable (as fate). Thanks Microsoft!
Might be bad, but sometimes its needed.
Where can I download IE6 to test a website?
If you are on windows, use IETester: http://www.my-debugbar.com/wiki/IETester/HomePage
For some reason, IE tester was not giving me the appropriate IE6 results. So I i’m using IE6 standalone along with IE7 in WIndows XP here is the link for standalone IE6 http://tredosoft.com/Multiple_IE
My recent experience with the Blackberry Browser is changing my attitude towards browser detection:
http://supportforums.blackberry.com/rim/board/message?board.id=browser_dev&thread.id=817
Sometimes you just need to know when you are dealing with a broken piece of software.
What do you think about browser-specific CSS? As maintenance goes on it seems to be a necessary evil.
I do think it’s a necessary evil. CSS isn’t really capable of browser detection or capability testing all by itself, so it’s pretty much our only option.
I guess I am talking more about JavaScript detection (or any means that could detect user-agent string and do something about it) and redirect or serve up special content or stuff like that.
With regard to JS user agent detection, and serving up “special content,” let me propose a situation to you…
Say that you were a large company, and a leader in standards progression and web development. Perhaps a company like, I don’t know, Google or something;P
And let’s say that you wanted to “do your part” to encourage users to leave IE6 in favor of FF, Chrome, or WebKit.
How, exactly, do you propose making the decision to show the “upgrade for better service” notice if not for browser detection?
This is just a simple situation, but you get the point. Oh, and it’s true as well.
Then again, Google is all for the table-layouts, doesn’t use DOCTYPE-declarations and uses deprecated tags like
<center>.I guess the rule goes like this: If you want to reach everyone on any computer (especially old ones with old browsers), use old markup. Design like it’s ’97 all over again…Chris, I’ll have to respectfully disagree with you here. Many times the “capability detection” is exactly done via “browser detection.”
I say that you should always serve up the same (X)HTML content, regardless of the access device. The site should be at least usable in Lynx.
The decision with regards to CSS (the presentation layer) absolutely SHOULD depend on the browser. Take your example: iPhone. While you CAN access the same web page with the iPhone, being able to offer an interface that caters to the device is most certainly appreciated by heavy mobile users. Navigation comes to mind here. Large fingers + small screens = hard to navigate, even if the user’s device “can” display “real” web pages.
Also, with regard to conditional styles, ala IE6, there’s nothing wrong with a little tweak here and there. I wouldn’t go so far as to say people should “cater” to IE6, by any means. But you really need to think about progressive enhancement, and sometimes you can’t really “detect” the capabilities without first detecting the browser.
Then, of course, you’ve got your behavior layer. Although with AJAX frameworks like Prototype, jQuery and the like, we’re already abstracting away the differences between IE and, well, everything else with the remote calls. This capability detection with straight JS is pretty easy for the most part: they either have it turned on, or they don’t.
However, really, really heavy client-side processing will again suffer on the mobile side. If you know your user is on a mobile browser, and thus a very low-powered mobile device, you probably wouldn’t want to offload a lot of processing from the server to the client. The iPhone is pretty capable, but like all other smartphones, suffers quite a bit in the processor and memory department.
I understand what you’re trying to get at; however, it does come across as being pretty strict in theory, but not beneficial in practice. As another poster mentioned, you yourself are using browser detection for IE issues ;P
The first JavaScript library to remove browser sniffing is jQuery in 1.3.
A funny story is that there was a panel at The Ajax Experience where John Resig was laughed at for mentioning removing browser sniffing. They said it was impossible, the fact is he just did it!
I can’t agree more!
So a person with Firefox at home should get the exact same webpage for the NY Times as someone on a Blackberry? The screens are completely different sizes. Javascript support on a BB is spotty.
I’m pretty sure this is not what Chris is suggesting, and why instead of browser detection you should do capabilities detection. One of the things to detect is the window size, assume your user is going to be using the smallest, crappiest browser ever invented and move up from there. By using javascript you can more or less determine just how good the browser/display of the user is and get the site to change the stylesheet accordingly.
Of course, that’s assuming you CAN use JS to detect these things.
In the small percentage of cases that a user has JS off, then the next best thing would be the user agent string on the server-side.
And in the even smaller case that the user has JS off, and is spoofing their user agent…well, let the chips fall where they may, I suppose. Just make sure all content is accessible, and the whole site basically works with no JS, no CSS, and no images.
If you’re talking about detection with Javascript, I imagine most frameworks use capability detection. For instance, Mootools determines browser engine. Example for detecting trident (Internet Explorer):
return (!window.ActiveXObject) ? false : ((window.XMLHttpRequest) ? 5 : 4);
sets Browser.Engine.trident to trident4/trident5 if in IE.
But it feels so good to tell the people on IE that their browser is lousy…
Sure I’m against not allowing the people on a bad browser, but still, I can discreetly tell them…
On my website (http://www.loriskumo.com) I used a small picture on the top-right to invite my visitors to switch on FireFox insted of being on IE. But if they dan’t want to, they can visit it anyway.
It’s what I call my little fight against IE…
Nice post… detecting browsers is a pain in the butt!
jQuery is no longer using browser sniffing, they are using featured detection as Chris mentioned to avoid headaches and problems in the future. Sorry if someone mentioned this, but I didn’t see it.
At handsetdetection.com we use the user-agent plus other headers to provide capabilities on mobile/cell phones.
I disagree with your assertion that special content is evil.
If a customer wants an iPhone optimized experience then why not give it to them ? Sure the iPhone can display normal content, but why not tailor the experience if you know its an iPhone ?
I think when you’re using the browser detection to detect if the user uses a PC or an IPhone thats just fine. Probably you can see it like thats only used as a method to detect the used device or machine and the Browser isn’t the important thing about it.
I think browser detection for the iphone is good. Im going to have a full flash site soon enough — never — so Id like to have this as a backup…but what do I know…I suck at this stuff anyway
but IE6 is just too bad for me. I’m new in designing world.. IE6 is not my era I could say.. i’m not using anything to solve problem with IE stuff.. just leave it that way.. maybe it is not good thing.. but at least that how give statement”don’t use IE”.
I agree that browser detection is bad. And I just wanted to share this example of browser detection gone horribly wrong. The version of the Ubiquity extension is treated as the version of Firefox: http://flickr.com/photos/spiri/3274163228/
I don’t totally understand feature detection.
Most of the browser detection code in my scripts are to work around very obscure browser bugs and usually are only for a single browser at a time.
I doubt libraries are going to detect all of these little browser bugs and then mark them as features for me to check against. What if multiple browsers have implemented a feature but one is buggy in places and I need to work with it differently?
What I see happening is that I will end up having to grab and test multiple features so I can target a specific browser and try to fix the bug. In the end it is still going to be browser detection but a roundabout way of doing it buy looking at features to determine what browser I am working with.
I see how it gets us away from trusting the user agent strings to detect browsers. Either way I am still going to want some way to do browser and version detection whether it is done by detecting user agent strings or feature detection.
I would love to see libraries keeping browser detection functionality but basing it off of feature detection. Give us a more accurate browser detection and let us use it or feature detection depending on what works best for us.
I know this is an old thread but it still appears towards the top of Google.
Firefox font rendering is much denser than that of Chrome or Safari for some Serif fonts. Tweaking the css letter-spacing property specifically for Firefox makes a big difference to readability
Browser detection is useful in this case, unless anyone can suggest a better method?