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

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 2

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).