Keep CSS Simple
When I wrote my first Keep it Simple column I assumed the old, overly-complex way of looking at Web site creation was on the way out. Web developers were consciously moving towards a simpler way of making sites, or so I fondly imagined.
Not so. The complexity monster has reappeared, right in the center of modern Web development. Nowadays it doesn’t manifest itself as an endlessly nested table but as an endlessly complicated CSS hack.
Our beloved CSS is in danger.
The lure of CSS hacks
Especially during the first half of this year, otherwise, sensible Web developers wasted enormous amounts of time in finding and improving countless CSS hacks. In my opinion, these hacks are a danger to Web development, both from a psychological and from a technical point of view.
Complicated CSS hacks are the modern equivalents of the frames and tables we used in wholesale lots back in the nineties. Their use serves to give the Web author a feeling of mastery, a false sense of security in the face of the countless things that can go wrong in browsers.
As a bonus, complex CSS hacks look great on mailing lists: “Five pixels too many in IE 5.5 Win2000 SP1.1beta? Use Funny Fred’s Hilarious Replaced Right-Bracket Hack!” Such mails are meant to dazzle the newbies and to prove that the author really knows what he’s talking about.
What bothers me most about the mindset of CSS hackers is that they are actively searching for complicated solutions. Seek and ye shall be found, if you want complexity it’ll take you by the throat. It’ll never let go of you, and it won’t help you, either.
The Web is an uncertain place. You’ll never be sure that your Web sites will work in the exact way you want them to work, not even when you apply all modern insights from CSS, accessibility, and usability. Instead of seeking false comfort in hacks that seem all the more comfortable because of their complexity, you should accept uncertainty as a basic principle.
Browsers don’t have perfect CSS support; especially for people who’ve just started learning CSS, which can be infuriating. Nonetheless, CSS hacks are not the solution. Acceptance of the way the Web currently works is the best way to go because it’ll keep your sites simple.
The dangers of CSS hacks
Besides, CSS hacks are actively dangerous for your Web site. A cursory glance at the underlying “theory” (if one can call it that) will rapidly convince you that the average CSS hacker doesn’t have the faintest idea what he’s doing.
A certain browser has a certain CSS bug. Good to know. This same browser has another bug, usually in its parsing of CSS selectors or comments. This, too, is important information. However, a CSS hacker proceeds to use the second bug to “solve” the first one.
Solving one bug by another is not my idea of keeping Web development simple, but the matter goes beyond bad coding style. These hacks are inherently unsafe.
In an ideal world, the next release of the browser would solve both bugs. In an uncaring world, the next release of the browser would solve neither. In the uncertain world, we live in the next release could solve one bug but not the other!
Therefore you could end up with a hack that applies an extra rule you no longer need, or with a necessary extra rule that isn’t applied anymore.
CSS hackers seek out pairs of complicated, transitory browser bugs and confidently assume that new browser versions will never solve exactly one of two paired bugs. Then they deliberately sprinkle these bugs through the Web sites they code.
The worst part is that they seduce innocent newbies into copying their reprehensible habits by falsely promising them mastery over Web browsers.
I find their behavior very unprofessional and irresponsible. It’s not forward-compatible Web development. It’s not backward-compatible, either. It’s completely incompatible Web development, and future users of their sites will pay the price.
Using CSS hacks responsibly
Deep in my heart, I do not wish to apply any CSS hack. More often than not, though, when I create a site one browser proudly displays a bug. On encountering such a bug I first wonder whether it is acceptable. Does the 10px width difference really matter?
When the bug isn’t acceptable, I always look for real CSS solutions first, solutions that do not involve hacking my way through browser land. If they’re not around, I use two CSS hacks, but only two.
I routinely use the
@import hack against extreme cases of Netscape 4. More rarely, and always after an extended round of soul-searching, I use the commented backslash hack against Explorer 5 Mac.
These two hacks are safe. Netscape 4 and Explorer 5 Mac are not being developed anymore. What we have now are, for better or (usually) worse, the definitive, final versions of these browsers. There will never be a next version that could make a mess of your pages.
Hacks against dead browsers are safe, but hacks against the living aren’t. None of them. Ever.
We should not use CSS hacks except for those targeted at dead browsers, and even these with caution and only as a last resort.
CSS hacks lull Web developers into a false sense of security and into pride at the complexity of their solutions, while the underlying theory predicts long-term disaster. Don’t fall for these aberrations. Keep CSS simple.