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

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

Answer 2

Well hacks are quicker for the browser, but browser detection gives better readablity in your CSS if you structure it right. If you can make browser detection and at the same time can share the CSS between the browsers, and only have the different css in seperate files or whatever, then I would use browser detection - as this is something a newbie can understand, where CSS hacks is hard to understand if you don't know them

Answer 3

I prefer to use browser detection and put the browser-independent CSS into its own file.

The best solution, however, is to find CSS that is cross-compatible by default and just use that.

Answer 4

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 5

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

Yes. Client-side browser-detection breaks if JavaScript is deactivated and might not work correctly with future browser versions. The last reason is also true for CSS hacks. Server-side browser detection breaks if the user explicitly tries to break it, but it still might be a viable alternative.

What I would recommend:

Make sure that you're code works in the standars compliant browsers - ie develop in one or two of those and check browsershots.org afterwards. Most likely it will be possible to implement the desired outcome in all of them with one stylesheet.

Then, there's IE. If there are only a few issues, you could go with a CSS hack. Otherwise, use conditional comments.

Edit:

If I have to support ancient browser's as well, I generally go the way of graceful degradation: I'll just let them show the pure html with a basic stylesheet (font sizes, colors, ...). All the fancy stuff will be hidden with an @import rule.

Answer 6

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 7

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.

You shouldn't have to test 'proper' CSS hacks on every browser.

The idea is that you write standards-compliant code, and then add specific hacks to target one and only one browser (or rendering engine) that makes a mistake. For example, writing "* html #myelement" to target an exception for IE6 only: no other browser will ever be affected by that hack so there's no need to test it exhaustively. It could only go wrong if some new obscure browser came along and made exactly the same mistake as IE6, which is extremely unlikely, not your fault, and something you could expect to get fixed quickly.

There are some things that call themselves CSS hacks but which use invalid constructs, such as the "_propertyname" hack. This can break across browsers because when you use invalid code every browser might interpret it differently. Don't use these.

To be honest, it is in any case not the issue it once was, primarily because IE5 is dead. If you use a Standards Mode doctype and write to the standards, it will mostly work in the current round of browsers. The only real remaining problem case is IE6, which you can target with "* html"; it is unlikely you will need much more in the way of CSS hacks than that. The days of the Box Model Hack are, thankfully, over.

Answer 8

I try not to use either. In a lot of cases the issues that IE have can be avoided by simplifying the structure of your markup somewhat.

It also helps if you use a decent CSS reset like Eric Meyer's.

I am also slowly but surely dropping support for IE6 as a matter of principle, especially given the latest security issues with IE6 and IE7 - we're not going to change people's browsing habits and browser preferences if we keep supporting crappy browsers.

Answer 9

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 10

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 11

There is a good article which tells you about how to use hacks for different browsers.

Answer 12

CSS hacks are not the way to go because browsers are updated all the time, and new updates may break your hacks, while with Javascript browser detection, you can accurately confirm the capabilities of the browser. However, another option is to use minimal CSS as to make sure that everything is working in all situations. JQuery and other javascript libraries that are for the UI have built-in detection as to the capabilities of browsers, so you should check those out.

Answer 13

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 14

hacks will always add to your work efforts and work efforts should be optimized

first you add the hacks and then start worrying about how they behave on different browsers and different machine.

instead you can rely on vendor specific css extensions http://reference.sitepoint.com/css/vendorspecific

Answer 15

[My approach][1] using a PHP class to detect os, browser and browser version.

[1]: My approach using a PHP class to detect os, browser and browser version http://reinholdweber.com/css/css-hacks-browser-version-detection-a-new-approach/

Answer 16

In 6 years of writing HTML and CSS for a living, the vast majority of my CSS issues have come from Internet Explorer.

As pointed out in other answers, you can use conditional comments to serve additional stylesheets to IE (or just to add a class to the <body> element, if you don’t like multiple stylesheets). Unlike CSS hacks, conditional comments are explicit and supported. Unlike trying to detect IE from the user-agent string, they’re guaranteed to work.

As for non-IE CSS issues, I’ve never found one that was worth browser detection. I prefer keeping all the CSS in CSS files.