o2b.net : Tim Murtaugh

There’s an article over at Stylegala entitled No More CSS Hacks. It describes a method of using server-side script to detect a user’s browser type (instead of the traditional client-side methods) so you can write browser-specific CSS without resorting to javascript or CSS hacks.

At first glance, it sounds good. Thinking on it a bit, the examples they show would be a slight nightmare for the way I work. On a regular basis, I build fairly large, very corporate CSS-driven sites with challenging CMSs (read as: I work with integrators that aren’t always 100% familiar with HTML, much less well-formed HTML) and challenging designs (read as: designs that look good, but aren’t always conceived with ease-of-production in mind).

The upshot being I write long, dense, complicated CSS files that, on a good day, can be hard to parse (by humans, I mean).

Fortunately, I’m able to keep my CSS hacks to a minimum. The only hack I ever need these days is the IE underscore hack. If you’re not familiar:

div.foo {color: red; _color: blue;}

In IE, the color applied is blue, in all other browsers, red. The really nice things about the underscore hack is that it’s unintrusive, yet easy to spot by eye. It can be placed immediately following the item it’s overriding, so I can easily tell what is being “fixed.” In addition, making sure to throw IE6 into quirks mode means I get IE5 & 6 compatability at the same time, and the high quality of the other browsers we support (Firefox, Safari) means that I only have to hack for IE. (Not to say I don’t have other browser-related problems, but I’m able to fix them without CSS hacks.)

Anyway, back to the point. Applying the server-side techniques as they’ve laid them out, would make my CSS files a swamp of unreadable code, which isn’t acceptable, seeing as I often have to hand projects off to other developers (not to mention the client) once the initial development has occured.

That having been said, I do see a very graceful way to make use of server-side browser detection: Sniff for browsers in the HTML file, not the CSS file, and instead of writing browser-specific CSS, write a call to browser-specific CSS files. So, along with styles.css you can also have ie.css and safari.css and firefox.css, which are only written when the server detects those browsers.

It would still mean changing the way I write CSS a bit. Instead of the underscore hack, I’d write something like this:

div.foo {color: red;} /* color overwritten in ie.css */

This way I (or a future developer) wouldn’t have to be intimately familiar with the alternate CSS files, and wouldn’t go insane because I can’t figure out why the text is STILL RED in IE. (Believe me, I’ve torn out many a hair trying to debug something that was being overwritten farther down in the CSS file.)

It’s conceivable that CSS files might become a mess of comments, but which is better — a mess of human-readable comments? Or a mess of computer-readable PHP?