Being still under development (specially some CSS3 modules) there are still parts of the CSS3 that is not well or at all interpreted well by some browsers. Sometimes that means a limited browser support for emerging standards, and other times it means having to go back and rewrite your code when draft standards change.

Vendor specific prefixes

When it comes to the still-in-progress CSS3 specs, not only does browser support vary widely (at the moment of writing this essay), but most browsers have implemented what are known 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 CSS3, you’d use a border-radius to define them. But because border-radius is still being finalized, browsers still 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 -o-border-radius.

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 an absolute standards conformance in your CSS code, you’ll need to stay away from vendor prefixes.

However, if you want to play with CSS3′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 CSS3.

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-top-right. Without the prefix, you’d have to deal with two different CSS rules, potentially forever, with one of them eventually being deprecated, 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.

NOTE: 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.


›› go to examples ››