Friday, August 4th, 2006

The Dangers of Browser Detect

Category: Browsers, CSS, Editorial, JavaScript, Programming

Picking up on the Rafael Lima’s new script to provide browser-detecting CSS selectors, PPK cautions on the dangers of browser detection.

Rafael Lima’s script adds classes to HTML elements based on the results of an old-style (ie. purely navigator.userAgent-based) browser detect. The purpose is to allow web developers to add CSS rules for one browser by using these classes … 37 Signals and Ajaxian enthousiastically covered it; in fact, the script was written as a result of the 37 Signals blog entry. Unfortunately neither 37 Signals nor Ajaxian seem to have considered the problems.

He says there are two problems here. Firstly, browser detection doesn’t always work.

This is the first, and clearest, danger. Browser vendors have been avoiding browser detects since 1994 by changing their navigator.userAgent value to what the browser detects script expect. Does the script expect “MSIE”? Then the user agent string contains “MSIE”, even though the browser is not in fact Internet Explorer.

Browser detection is something of a cat-and-mouse game, with manufacturers always finding new ways to convince scripts they’re IE or someone else and scripters finding cunning ways to reveal their true identity.

The other problem is browser versions – what if Opera 10 works different from Opera 9, do you want a separate opera10 selector?

Using a browser detect means that you have to constanly maintain the site that contains it: professionalism requires you to keep an eye on new browsers, check all your sites in them, and update the special rules for or against this or that browser that you’ve added. This quickly leads to a maintenance hell—one of your own making.

The proposed solution is to detect old versions of IE6, and try to come up with a universal solution for the modern browsers, and PPK acknowledges that’s not trivial, as CSS certainly won’t always work the same way.

Arguments against browser detection are fair, but sometimes it’s the right approach from a pragmatic perspective. Especially when using third-party libraries, if you find something’s simply not working on a certain browser, what do you do? If you have real-world deadlines, you often don’t have time to dive into the code and work out why it fails to work on Opera 9 and Firefox 1.0, but works fine everywhere else. Instead, you may have to take the pragmatic approach and use slightly different CSS or code, at least as a temporary measure. Having said that, you don’t want to do that too often … as PPK points out, a proliferation of browser-specific handling is definitely going to cause maintenance hassles.

Posted by Michael Mahemoff at 10:09 am
8 Comments

++++-
4.1 rating from 60 votes

8 Comments »

Comments feed TrackBack URI

What are we building standards for if we then reward different browsers for breaking them? The author certainly has a point, why should the developers find workarounds for problems in the browser that are not standard compliant?
I know it’s not a good idea to let users smash into a wall because they use a crappy browser but sooner or later they will get it (i hope…).

Comment by Christian 'Snyke' Decker — August 4, 2006

I don’t think it’s a question of “rewarding” browsers for breaking things like the DOM standards. You’re right that it’s not a good idea to let users smash into a wall because they’re using a poor browser, but hoping that “sooner or later” they will get it may not be the right idea.

For example, many people are stuck using IE6 without choice. Perhaps it’s because of their institution’s software policy, which may prevent installation of other browsers. Now before someone chimes in with “Portable Firefox”, remember that sometimes people just don’t want to break the AUP on their institution’s computers.

But the bigger problem is the mainstream user who will never care what browser they use and will always use the default that came with Windows. Being in the tech world, it’s easy to forget about the “average” user and quickly develop an attitude of “why would anyone use IE?”. This is a bad idea to develop – it implies a misunderstanding of the average user and their needs. The fact remains that when designing a corporate website (or any website designed for the masses), cross browser compatibility is an important aspect.

I’m not pro-browser sniffing (I think it’s a bad idea as per PPK’s reasons), but the extra work may be necessary in some cases.

Comment by Peter — August 5, 2006

I only check for one web browser. MSIE. So I have one config that is the default for everyone. Then I have another config that’s for MSIE. I expect that all browsers other than MSIE are standards compliant. If they aren’t then something may not look right. I only make exceptions for MSIE because of the size of the user base. I don’t go out of my way to make MSIE work right, I just do the minimum. I focus on standard compliant code and I use Mozilla and Safari to test. Later I go back and make things work in MSIE (and I charge more too).

Comment by Phill Kenoyer — August 5, 2006

Whatever has been mentioned is true and it would be of tremendous help to the entire web community if the browser vendors themselves looked to bridge the gap for the scripts to become universally executable which today forms a headaches for developers.

But looking at the current situation where everything has become stabilised and users have been divided into groups either belonging to MSIE, Mozilla, Opera, etc. As is it possible as of now for the vendors to adhere to some standardised specifications. But that would be more aggravatign the problem as the older applications would become useless if at all the object model would have to be changed.

Can there be a solution for this?

Comment by Nitin — August 7, 2006

I thought that the best solution to detect a browser is not to check it’s navigator.appName, but browser’s capabilities. In example, if it supports activeX, document.images, DOM, window.opera, document.all etc.

Comment by MisYu — August 7, 2006

PPK wrote about “object detection” as opposed to browser version sniffing, the idea is solid (as MisYu mentioned above.)

http://www.quirksmode.org/js/support.html

Comment by Scott Schiller — August 7, 2006

I will agree that a script such as this should be used as a last resort, but I’m not convinced by the “problems” of this technique.

The first problem concerning browsers masquerading as MSIE is valid but completely out of a developer’s control. I agree with Peter that most users will use whatever comes with his/her computer. Having worked on many large-scale sites, support for IE is always the #1 concern, with Firefox #2 and Mac browsers (Safari and Firefox) coming at #3. The others simply need to work not necessarily display properly. This is a necessary compromise for small-share browsers. It is not cost-effective to tweak for Opera when so few people use it. Thus if browser makers want to ‘fool’ us, they should be held responsible for displaying pages properly for that User-Agent.

As for the second problem, what is the problem? Common browser “feature” detection arguments just don’t apply here. These types of CSS adjustments are targeted for specific browsers. Usually older ones that don’t fully support CSS. If Opera 9 and Opera 10 display differently then you should have a rule for each. A good developer must be aware of new browsers and assure that the pages display properly. Many companies now are scrambling to adjust pages for IE7 and dealing with their own maintenance nightmares.

I believe the words of caution in this article are designed to dissuade quick hacks – simply using this script instead of working to solve the problem. A script like this would be best to supplement CSS rules to fix common problems like float clearing. I agree that using it to adjust the right margin for one class on one page and another one on another page could lead to monumental problems. However, being smart about CSS coding to avoiding common pitfalls is the best approach while using the script to simply make some global adjustments. The number of problems with CSS in modern browsers is finite and manageable. What might be a nightmare for one person or organization may not always be for another? Too many developers are way too accomodating. If Opera wants to change their CSS interpretation or act like it is Lynx or whatever else they change from release to release, I’m not going to be there to dissect it and rush to adjust my codebase.

Why is there not more criticism of these browsers? Probably because so few people have actually used them. I love an underdog and hate Microsoft too, but come on!

Comment by zack Frazier — August 10, 2006

Object detection is great, and should be used in preference to browser detection (or CSS filters) wherever possible. But it’s not always possible. How do you detect if a browser is using say, Presto to render things? Unfortunately, the only way is browser sniffing.

Comment by mc — August 23, 2007

Leave a comment

You must be logged in to post a comment.