Working Around CSS3 Hacks

Until CSS3 is a final specification, we can expect to see browser makers attempting to implement some of the ideas on their own, sometimes with a nod to the forthcoming spec and sometimes without a clear correlation. Given the pressure for browser makers to claim support for a CSS3 feature as soon as possible (Does Your Browser Really Support HTML5 and CSS3? and HTML5 and CSS3 Confusion), these implementations aren’t always complete or terribly close to what the final specification will require. If you’re the kind of developer who just cannot wait for the W3C to wrap things up (and they still haven’t finished CSS 2.1: CSS 2.1 Still Not Final), then you probably want to try your hand at using these new features, at least implemented by the browser makers. Take some time to read up on some best-practices articles that can save you a lot of time down the road as you have to re-factor your code.

In late June the article Stop Forking with CSS3 showed up on A List Apart and promoted the use of a JavaScript library over browser-specific prefixes (vendor prefixes). The author felt that the pre-pended CSS styles (such as -moz, -webkit, -o, and -khtml) were just the modern form of CSS hacks we’ve been using as patches through a decade of shoddy support from browsers. I am not a fan of using client-side script to make my CSS (or HTML) coding easier — I don’t like to put the processing burden on every end user instead of simply writing more code. Others agreed, as this sample comment (from Bruce Lawson) highlights: vendor prefixes are a feature, not a bug

Bruce Lawson proposed his own approach in early June, Writing cross-browser, future-proof CSS 3. He argues that developers need to learn the standards in the specification and include them in the code, regardless of browser support. Then a developer can add the browser-specific hacks on top of that. This way when support for the standard emerges, no code changes are necessary. As browsers start to drop support for their browser-specific hacks, still no code changes are necessary. This is valuable for contract work when your client pays you to develop and deploy a site and months later the rules change. Now you don’t get a panicked phone call about changes to the site appearance and you don’t have to incur expense (yours or the clients) to fix your code. Some of the comments on the post discuss ways to separate and format the browser specific styles for later removal.

Earlier this month Eric Meyer weighs in at A List Apart with Prefix or Posthack. Here he suggests that browser-specific prefixes are the best way for browser makers to introduce new support. As the specification and/or the support is/are finalized, then browser makers should drop the prefixes. As developers, these prefixes are clues that things are still in a state of flux. At the very least, if implementations differ dramatically, it’s far easier to include a prefix to specifically target each browser than to look for hacks or write browser-sniffing scripts.

Loathe though I am to write any browser-specific code, I endorse the approach outlined by Eric Meyer. Add in some of Bruse Lawson’s suggestions (such as ordering the prefixes in alphabetical order) and you should have future-friendly CSS that doesn’t exist solely at the whim of browser makers, but still allows you to play with these new CSS toys.