demosthenes.info

I’m Dudley Storey, the author of Pro CSS3 Animation. This is my blog, where I talk about web design and development with , and . To receive more information, including news, updates, and tips, you should follow me on Twitter or add me on Google+.

web developer guide

my books

Book cover of Pro CSS3 AnimationPro CSS3 Animation, Apress, 2013

my projects

CSSslidy: an auto-generated #RWD image slider. 3.8K of JS, no JQuery. Drop in images, add a line of CSS. Done.

tipster.ioAutomatically provides local tipping customs and percentages for services anywhere.

CSS Vendor Prefixes and Flags

css / introduction

Estimated reading time: 3 minutes, 9 seconds

Many 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:

PrefixBrowserExample
-mozFirefox-moz-border-radius: 5px;
-oOpera-o-transition-delay: 5s;
-webkitSafari / Chrome-webkit-mask-image: url(circle.svg)
-msInternet Explorer 9+-ms-transform-origin: centre;

(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.

As browsers are updated, more will support the final version of the property, making prefixed code increasingly redundant. border-radius is a good example of this: today, every modern browser supports the final, non-prefixed 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's auto-generation of prefixed code, 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.

comments powered by Disqus

This site helps millions of visitors while remaining ad-free. For less than the price of a cup of coffee, you can help pay for bandwidth and server costs while encouraging further articles.