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

Answer 1

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 2

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 3

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 4

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 5

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 6

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.