Dealing With Browser Differences in CSS 3
Cutting edge web technologies never come without a cost.
Sometimes it means limited browser support for emerging standards, and other times it means having to go back and rewrite your code when draft standards change.
When it comes to the still-in-progress CSS 3 spec, not only does browser support vary widely, but most browsers have implemented what are know as vendor-specific prefixes. The prefixes complicate things, and they require more work to drop them into your code, but they do serve a purpose.
For example, if you want rounded corners in CSS 3, you’d use
border-radius to define them. But because border-radius is still being finalized, browsers only support their own versions of the rule. So,
-moz-border-radius will target Firefox,
-webkit-border-radius targets Safari and Chrome. For Opera, it’s
None of the special prefixes will validate, which is less than ideal. There’s a suggestion floating around that CSS validators should change their behavior regarding vendor prefixes by issuing a warning instead of an error. Regardless, if you want absolute standards conformance in your CSS code, you’ll need to stay away from vendor prefixes.
However, if you want to play with CSS 3′s new toys, you’ll see there are some very good reasons why vendor-specific prefixes exist, and why you should use them (for now) in addition to the actual proposed rules of CSS 3.
To stick with the border-radius example, consider what happens when you want to target just one corner of an object. The spec was in flux in when the WebKit project decided to use
-webkit-border-top-right-radius and Mozilla went with
-moz-border-radius-topright. Without the prefix, you’d have to deal with two different CSS rules, potentially forever, with one of them eventually being depricated, but still out there in older versions of that browser.
Both prefixes are technically “wrong” and that’s a good thing. Eventually, the final spec will be published and only one rule will be standardized, with all browsers implementing that rule. At that point, you can simply go into your code and delete all of your prefix rules. The vendor names make them easy to find and zap.
One thing you should definitely not do is target only one browser’s prefixes. As Apple’s disingenuous “HTML5″ showcase recently highlighted, optimizing for a single browser is never a good idea.
Gustafson refers to vendor prefixes as “forking” CSS. While we agree with his point, the word “forking” is problematic if only because there is nothing wrong with forking code. In fact, it’s the norm in the open source world. (You are using Git or Mercurial right?). And vendor prefixes are not forks, they’re hacks — temporary ways to push the boundaries of the web while standards bodies catch up.
Terminology aside, Gustafson’s point is valid — ignoring standards and littering your CSS with browser-specific code are both bad ideas.