What is better: CSS hacks or browser detection?

Question

Commonly when I look around the Internet, I find that people are generally using CSS hacks to make their website look the same in all browsers. Personally, I have found this to be quite time consuming to find all of these hacks and test them; each change you make you have to test in 4+ browsers to make sure it didn't break anything else.

About a year ago, I looked around the Internet for what other major sites are using (Yahoo, Google, BBC, etc) and found that most of them are doing some form of browser detection (JS, HTML if statements, server based). I have started doing this as well. On almost all of the sites I have worked on recently, I use jQuery, so I use the built in browser detection.

Is there a reason you use or don't use either of these?

Answer 1

Carefully consider everything above, especially pointers about doctype. If you must apply a CSS hack, for a specific browser know that hacks are almost always avoidable. Especially for a dry static page.

Speaking from limited experience developing these things... I am assuming you want to make a slick Web page that flashes without the messy Adoobi boughtware:

• Code a page which looks reasonable on these browsers, all of which can be tested on one machine:

Op3ra 9.6, S@fari 3, Chr0me 1, 1nternet Xpl0rer 6, 7 & 8, Firefux 1.5

• Use the @import css rule to ditch the css in ancient browsers and let them eat cake.

• Use a combination of object detection and browser sniffing to find and eliminate problem browsers (all versions below the targetted above). Also catch the ancient browsers you know aren't up to speed (css property you can test and compare to known value) just in case they make it past the sniffer, also use conditional comments to kick out 1E5 feeding it some anti-css to calm it down on its way, similar for ie6 except keep it in the jQu3ry if at all possible.

• Use a dynamic element to load the jQu3ry libray into the allowed browsers (any which has not failed your careful tests). I.e. we don't even import the library when we know it is not going to work / we let everyone else in.

• Use jQu3ry to address any problems in your supported browsers, most of which will only come to light when your pages become dynamic. Use jQu3ry to enhance the layout and add in your interface etc...

• Expand on this with media statements and you could test for a css value unique to those devices, now you will have more knowledge to use in adjusting the layout (i.e. destroy those columns and shrink those images). Turn off animations and so on.

• Keep it accessible by always using text labels and some positioning tricks to make them disappear if you must Mr. flashy menu guy... just don't rely on images or Javascript alone to browse your sites.

• Its easy enough to block anything below Netsc@pe 4. Giving them just the basic Web, the way it was meant to be originally. I.e. don't even specify a background or color, or font or anything for them. The browser's defaults should work fine. The information will be accessible.

In fact, I move that all "accessible" browsers ID themselves as N$4 so we can easily nuke them out of the dynamic presentation and keep ourselves from screwing over the handicapped.

Alas she was a good ship but even a good ship for scaring the ever-lying out of M$ must die. Do not fear for we have an even better one now ;)

---

Just my 2 cents, apply with caution.

Answer 2

There is a third option:

Minimize or eliminate the need for browser detection and CSS hacks.

I try to use things like jQuery plug-ins that take care of any browser differences for you (for widgets and the like). This doesn't take care of everything but it does a lot and has delegated the effort of supporting multiple browsers to someone who has spent and will spend far more effort on it than you can afford to or want to.

After that I follow these princples:

• Use what I call minimal CSS, meaning only use features that are widely supported;
• Use tables for complex layout if necessary. You may not like this but frankly to do things like side-by-side layout, tables will work on browsers going back a decade and will be a lot less effort than getting divs to work with combinations of absolute positioning, floating and the like;
• Force IE6 into strict rather than quirks mode by adding a DOCTYPE. I can't stress how much easier this will make your life but oddly many people don't seem to do it still;
• Minimize box model issues by either using the correct DOCTYPE or using nested block elements rather than the other box model hacks; and
• If necessary include extra CSS files for relevant browsers. I tend to do this on the server rather than the client with generated pages (which, let's face it, is most of them). Many projects I've worked on have had IEfix.css files.

After that, I divide browsers into tiers:

Tier 1:

• Firefox 3;
• IE7.

My website must work on these.

Tier 2:

• Firefox 2;
• Safari;
• Opera;
• Chrome.

My website should work on these. This may offend some people but frankly the market share of these browsers is so low that they're simply not as important as Firefox 3 or IE7.

Tier 3:

• IE6;
• Others.

Minimal effort will be made to work on these unless it is, for example, a company requirement. IE6 is the nightmare one but it's market share as of December was 20% and rapidly falling. Plus there are valid security concerns (on financial websites for example) for dissuading or even disallowing the use of IE6 such that sites like Paypal have blocked IE6 and Google tells users to drop IE6.

Answer 3

Listen to your code! Kent Beck says it. And in Wing-Tsun they say: be like the water that bends! Or something.

Look, here's a CSS Hack to get IE5 to understand html5: http://blog.whatwg.org/styling-ie-noscript.

And here's the same using JS: http://blog.whatwg.org/supporting-new-elements-in-ie.

Compare 5 pages of hack explanation with 5 lines of well-understandable code. So, use JS.

Things have their benefits and their downsides. And your understanding of the matter and the elegance of the actual code lead the way.

Answer 4

Whats wrong with detecting the browser server side? Seems very effective and foolproof (save for the user altering their user-agent string). You can use PHP to either choose the stylesheet for a page or dynamically generate it for each request - not sure if other languages let you output directly to the file and let you set the headers manually, but I can't imagine them not letting you identify the user-agent, so one of these options is probably viable for any server-side environment.

Answer 5

I generally like to have a stylesheet for standards-compliant browsers such as Firefox and Safari and then use conditional comments to detect Internet Explorer and serve it an additional CSS file containing IE-specific fixes and overrides.

Answer 6

The problem is that you only really get one shot at the css (since it is pretty much static content at the client)... you can't (easily) adapt it to suit on the fly at the client - so for those tricky incompatible cases (and there's too many of them), detection is sadly the best route. I can't see this changing very soon.

With javascript, you can often avoid much of this pain through libraries like (as you state) jQuery - and checking for functionality support rather than identifying the specific browser (most of the time). There are some cases you need to know exactly (the box model, for example).