In the comments of a recent article discussing conditional comments someone mentioned that they prefer to use PHP to detect which browser (user agent) and/or operating system is in use, then they display a custom class for the
<body> tag and target the browser accordingly in their CSS.
I’ve known for some time now that this is wrong. I was told that a user agent can be faked, so the people I’ve worked with discouraged this method, and I’ve never used it.
In no way am I an expert in this particular area, so I’m not claiming here to be able to fully explain exactly why we shouldn’t do this, but a little bit of quick research on this topic shows that server-side browser detection is not a good idea.
I’m not going to drag each of these points on (mostly because I don’t have the technical expertise in this area), but instead I’m just going to provide brief quotes and links that discourage the use of this method and provide further insight into the matter.
It Can be Done with HTML and CSS
This is the main reason that you shouldn’t use server-side logic for browser detection. Anytime you can deal with a client-side, presentational issue using pure client-side, presentational code, then you should do so. (UPDATE: Thanks to Jacob Gube for pointing out that this really should be the first reason listed.)
Making Code Harder to Maintain
The argument here is that by using server-side logic to affect the presentational layer, you’re unnecessarily creating less maintainable code.
This quote from a post on SitePoint forums sums it up best:
I don’t see why you would intentionally mix the presentation layer with server-side logic and hide away your fix in a non-standard way. For example… Possibly years down the line when you have left the employ of your client they wish to restyle the application and hire a designer to alter the CSS to suit. Why in the world would they look in the PHP source for this magical function of yours that is no longer relevant?
Faking the User Agent
I’ve already mentioned this one, but here is another quote from someone on SitePoint Forums regarding this issue:
I could easily have all the browsers on my computer set up so that the only one that doesn’t contain MSIE in the useragent field is Internet Explorer – if I did that then your code would break in all browsers. Don’t rely on a free format user controlled value that someone might change.
Also, there’s a website called AppTools.com that offers PHP scripts. They’ve removed an older PHP script that detected the user agent. Here is how the page sums up their reasons for removing the script:
Browser detection is an illusive task that is ultimately doomed to fail. Browsers are always changing and keeping up to date with these changes is a continuous job. Some browsers allow the user to alter the way the browser identifies itself, or to not identify itself at all. Some firewalls block the sending of the browser identification, so no browser detection scheme is entirely successful.
Dealing With the Complex User Agent String
Some responses on Stack Overflow about server-side browser detection show how complex this method can be, and how many issues you need to deal with when trying to detect the user agent. Here is a notable quote from one user:
Browser-sniffing on the server side is a losing game. Apart from all the issues of trying to parse the UA string, the browsers that lie, the obscure browsers, and the possibility the header isn’t there at all, if you return different page content for a different browser you must set the Vary header to include User-Agent, otherwise caching proxies may return the wrong version of the page to the wrong browser.
And if you get a chance, please read this hilarious article by Aaron Andersen that documents the history of the user agent string.
Anything to Add?
I think the basic reasons not to use server-side browser detection are covered above. If anyone has any further information, or wants to correct anything I’ve said or quoted here, please do so in the comments.
Like I said, I’m not an expert in this area, but I thought it would be important to point out the weaknesses in this method, and encourage developers to avoid this poor method for serving browser-targeted CSS to the client.