As the CSS3 Modules specifications have yet to be either ratified by the W3C or have all their proposed features fully implemented into browsers, browser vendors use what's known as vendor prefixes to test new "experimental" CSS features. Whilst this helps browser makers implement the new CSS3 modules, it makes our lives, as writers of CSS3, just a little more tedious. Consider the following code for a rounded corner in CSS3:

.round{
  -khtml-border-radius: 10px; /* Konqueror */
  -rim-border-radius: 10px; /* RIM */
  -ms-border-radius: 10px; /* Microsoft */
  -o-border-radius: 10px; /* Opera */
  -moz-border-radius: 10px; /* Mozilla (e.g Firefox) */
  -webkit-border-radius: 10px; /* Webkit (e.g. Safari and Chrome) */
  border-radius: 10px; /* W3C */
}

You can see a number of vendor prefixed properties (and that is by no means an exhaustive list), each with their own unique prefix, for example, -webkit- for Webkit based browsers, -ms- is the Microsoft prefix, so covers the Internet Explorer, and so on. Due to the way CSS works, a browser will go line by line down the stylesheet, applying properties that apply to it and ignoring ones that don't.

Furthermore, applicable properties later in the stylesheet take precedence over earlier ones. Thanks to this cascade, we can list our vendor-prefixed properties first and then the correct (but perhaps yet to be implemented) non-prefix version last, safe in the knowledge that when the feature is fully implemented, the correct version will be implemented by the browser, rather than the experimental, browser-specific one listed before it.

It's acceptable to list every vendor prefix version of a property. However, in reality, few people do. Instead they either target the browsers they expect to see most often or check what browsers support the feature before writing the rule. For example, you might just opt to go with:

.round{
  -moz-border-radius: 10px; /* Mozilla (e.g Firefox) */
  -webkit-border-radius: 10px; /* Webkit (e.g. Safari and Chrome) */
  border-radius: 10px; /* W3C */
}

That would cover Firefox, Chrome, and Safari, along with any browser that has fully implemented the rule.

I know what you're thinking, isn't listing multiple vendor prefixed versions of the same property going to lead to code bloat? Well, a little yes. But no matter how many prefixed properties we add, it's still a faster, more elegant and robust solution than using images.

Before working on a site, it's wise to look at the current browser usage statistics. In doing so, you'll have a better idea of what browsers you need to build specific support for. For example, if time and budget are tight, you might decide to omit vendor specific prefixes for any browser with less than 3 percent usage rate for your site. As ever, you need to make a judgment based on a number of variables.

Now, we understand what the prefixes are and how to apply them in our rules. Let's look at some quick and useful little CSS3 tricks.

Tip

When can I use specific CSS3 and HTML5 features?

As we delve into CSS3 more and more, I can heartily recommend visiting http://caniuse.com, if you ever want to know what the current level of browser support is available for a particular CSS3 or HTML5 feature. Alongside showing browser version support (searchable by feature) it also provides the most recent set of global usage statistics from http://gs.statcounter.com.