In this article, we’re going to cover the basics of CSS3 and vendor-specific browser extensions.
In the past ten years or so, CSS has been relatively standardized, and browser compatibility hasn’t been as much of an issue as it was in the old days of the 1990’s and Internet Explorer. However, since new browsers have implemented many of the CSS3 features differently, web developers now have to be more aware of browser compatibility issues.
The basic situation is that some CSS3 features are browser-specific for a period of time, but then they become W3C recommended, and in these cases they become standardized. But other features have only partially been implemented, and in that situation, you’ll have to use vendor-specific extensions, each of which might have slightly different operation.
When using CSS3, it’s important to look up a reference and see which CSS properties are standardized, and which aren’t. If a property has become standardized, refrain from using any of the vendor-specific equivalents.
When to Use Vendor-Specific Extensions
Frankly, the official recommendation from WC3 is not to use them. The better way to state this is to not rely on them. They can be useful for implementing cool properties that haven’t yet become standardized across browsers, and they can also make your site available to people using many different types of browsers, but they come with some complications.
First of all, the way they function can be changed at any time. They’re used as a test implementation, to work out the kinks of a CSS property before it becomes a standard feature. Consider them the working draft of a feature, which may or may not be subject to change.
This ultimately means that if you’ve got a real application being developed, where a company’s image is on the line, it’s best to avoid vendor-specific extensions altogether. The stakes are too high, and if one of the extensions underwent a modification, it could potentially break the site you’re building.
Testing and personal use can be helpful to web developers, though. One solid reason to play with vendor-specific extensions is that you’ll be ready to use the real thing as soon as it’s released. There are also a few cases where, if a feature is very close to being standardized, you can use vendor-specific tags to implement it on your website a bit early and have a smooth transition to the standard version by adding the regular CSS3 code as well.
The Common Vendor-Specific Extensions
The main vendor-specific extensions that you’ll want to become familiar with are:
Webkit-based browsers, like Safari and Chrome, which use the -webkit- tag;
Gecko-based browsers, like Firefox, which use the -moz- tag;
the proprietary Opera extension, which uses the -o- tag;
the Konqueror browser, which uses the -khtml- tag;
and the proprietary Internet Explorer extension, which uses the -ms- tag.
Using Vendor-Specific Extensions
Each of these tags serves as a prefix to the vendor-specific properties, so in this example of using the CSS transform property on an element, which used to be a non-standard feature, we would do the following:
transform: rotate(20deg); /*Covers current CSS3 and will be ignored by older browsers*/
-ms-transform: rotate(20deg); /*Covers IE 9*/
-webkit-transform: rotate(20deg); /* Covers Safari and Chrome */
-moz-transform: rotate(20deg); /* Covers older Mozilla browsers */
Each of the vendor-specific extensions has a running reference that can be located to find the exact status of their vendor-specific features. These lists will also include information on which vendor-specific features have now become standardized.
As of September 2013, the following list should be useful for developers looking for documentation on vendor-specific extensions:
Documentation on vendor-specific extensions isn’t always up to par compared to standard features of CSS, but that’s due to the very nature of vendor-specific extensions. For the major browsers, you should be able to find references relatively easily.