Many CSS modules remain in draft mode at the W3C, and will continue to be for some time to come. Meanwhile, browser developers are hungry to use proposed CSS properties. At the same time, they are very aware that the proposed implementation for any property currently in draft could change as the specification is hammered out.

The industry's initial response to this was to implement draft CSS properties with proprietary vendor prefixes unique to each browser. The main browser prefixes are:

(Note that there are many more vendor prefixes than those listed above, but you will find that the others are rarely called upon.)

The intention of vendor prefixes was to allow each browser to create its own interpretation of a proposed CSS property; when the property enters "final" status with the W3C, it is a simple change for browser vendors to drop their prefix in favour of the final version.

The value for a vendor-prefixed CSS property is often (but not always) the same between browsers: border-radius, shown below, is a good example.

As a rule, vendor prefixed properties are written first in any style declaration, with the final version of the property at the end:

div#mainbox {
	-moz-border-radius: 5px; 
	-webkit-border-radius: 5px; 
	border-radius: 5px;
}

Because declarations are read left-to-right, browsers that drop prefixes will ignore those properties and follow the final version.

Progressive Enhancement in CSS

It’s important to understand that vendor prefixes should be considered an enhancement to a page, rather than a requirement. A browser that doesn’t support box-shadow should still receive the same information as one that does, and present it in a readable format: it will just display the data slightly differently.

The Limitations of Vendor Prefixes

Vendor prefixes were an imperfect answer to the challenge of moving web standards forward, and generated several counter-productive behaviours in developers:

• The rapid adoption of Chrome and mobile Safari, combined with developer ignorance, led many web designers to concentrate on –webkit- prefixes, leaving other browsers with equal support out in the cold.
• Prefixed code complicates stylesheets, making CSS more difficult to build. Researching which browser versions need prefixes adds significantly to development time.
• Developers sometimes neglect to include the final version of the property at the end of the declaration, further slowing the drive to a final spec.
• Prefixes linger in stylesheets long after browsers have passed them by, making sites more difficult to optimize and maintain.
• Other developers take a “prefix all the things” approach to CSS, adding them when they are not needed and aimlessly expanding their stylesheets. Redundant -ms- prefixes are a good example of this: Microsoft often went directly to the final version of the CSS property in IE10, with no intervening prefixed step.

Solutions

Vendor prefixes were a well-intentioned and somewhat successful effort at progress, but came with unanticipated costs. Developers responded by trying to simplify prefix coding: Lea Verou’s -prefix-free, Sass auto-prefixed code with the appropriate mixins, and the prefixr utility all attempted to address the complex issues of generating and maintaining vendor prefixed code.

Long-term, the industry appears to be moving from prefixes to a flags approach, whereby individual users have the ability to turn “beta” features on and off in their own browsers. (To see an example of this, type about: flags into the URL bar in Chrome). This will simplify work from the developer's point of view, at the potential cost of less experimentation, as it will mostly be developers who are setting flags, not casual site visitors.

Photograph by Thanh Mai Bui Duy, used under a Creative Commons Attribution-NonCommercial 2.0 Generic license.

Enjoy this piece? I invite you to follow me at twitter.com/dudleystorey to learn more.