JavaScript

Should We Abolish CSS Vendor Prefixes?

    Craig Buckler
    Share

    Prefixes are the vendor-specific names tagged to the start of CSS properties. For example, you require the following code to rotate an element by 10°:

    
-moz-transform: rotate(10deg);		/* Firefox 3.5+ */
-o-transform: rotate(10deg);		/* Opera 10.5+ */
-webkit-transform: rotate(10deg);	/* Chrome and Safari3.1+ */
-ms-transform: rotate(10deg);		/* IE9 */
transform: rotate(10deg);

    (You could optionally use Microsoft’s DXImageTransform.Microsoft.Matrix filter to support IE6 and IE7).

    Why do we need prefixes?

    First, you should understand that web standards are not dictated by the W3C. The Consortium is not responsible for innovation — that’s left to browser vendors.

    For example, assume Opera invented a new CSS property named ‘polygon’ which magically transformed a rectangular element into a standard shape, e.g.

    
polygon: 6; /* a hexagon */

    Now consider that, by pure chance, Mozilla were also working on their own implementation of the polygon property. However, instead of a number of sides, Mozilla preferred a named value:

    
polygon: hexagon;

    It leaves web developers with a serious headache. If they want to use the polygon property, it’s impossible to support both browsers at the same time. A numeric value fails in Firefox and a named value fails in Opera.

    Vendor prefixes solve the problem, e.g.

    
-o-polygon: 6; /* Opera support */
-moz-polygon: hexagon; /* Firefox support */

    Microsoft and/or the webkit team could create their own polygon implementation. If two or more vendors agree, the polygon property will ultimately become part of the W3C CSS specification.

    The compatibility issue is highlighted by the relatively new background gradient syntax. The webkit team have implemented a fairly complex but versatile solution. Mozilla’s implementation is closer to the draft W3C specification — but that’s still a draft document and could change:

    
background-image: -webkit-gradient(linear,left top,left bottom,color-stop(0,#000000),color-stop(1,#ffffff));
background-image: -moz-linear-gradient(top,#000000,#ffffff);

    Are prefixes still necessary?

    The rotation example above highlights several issues:

    • the code is verbose
    • it’s too easy to forget a prefix, and
    • every vendor supports the same syntax.

    Prefixes are a solution to a problem that rarely occurs. Browser vendors do not work in isolation: Microsoft, Apple, Mozilla, Google and Opera are all W3C members and none would implement their own feature without referring to what others were doing.

    Consider the -webkit-transition properties. The webkit team are leading CSS transition development and others are following. So why is the prefix necessary? Vendors are unlikely to deviate from webkit’s implementation. Serious technical problems or flawed ideas are likely to be fixed by the webkit team first.

    But it’s not just newer properties. Border-radius has been available for several years and every vendor implements the same syntax. Yet, to ensure good browser compatibility, developers still need to use:

    
-moz-border-radius: 10px;
-webkit-border-radius: 10px;
border-radius: 10px;

    Vendors have their own opinions about when a property is “standard” enough. It will be many years before the vendor-specific border-radius properties die.

    CSS guru Peter-Paul Koch has been particularly scathing about prefixes on his QuirksMode blog:

    It’s time to abolish all vendor prefixes. They’ve become solutions for which there is no problem, and they are actively harming web standards.

    Should CSS prefixes be abolished?

    Are vendor prefixes still required in an age of increased browser cooperation? I doubt any developer wants to use prefixes, but are they a necessary evil? Would it be better if vendors added properties without prefixes, but made it clear they were experimental and not (yet) a standard?

    That’s the topic for this week’s SitePoint poll. Please cast your vote and leave your comments below…