The Impending CSS Vendor Prefix Catastrophe

Key Takeaways

• The overuse of CSS vendor prefixes, particularly the -webkit prefix, creates potential issues for web standards and cross-browser compatibility. Developers often use these prefixes to access new features, but this can lead to non-standardized, browser-specific code.
• The World Wide Web Consortium (W3C) is considering supporting the -webkit prefix in non-webkit browsers. However, this could lead to incompatible implementations of the same property and further encourage developers to use webkit-specific properties, potentially making them a de facto standard.
• The responsibility for this issue lies with both developers and browser vendors. Developers need to avoid writing browser-specific code and test their sites in multiple browsers. Meanwhile, browser vendors should provide more information about the standardization status of prefixed properties and highlight when they become obsolete.

Developers have a love-hate relationship with CSS vendor prefixes. They allow us to use bleeding-edge technologies at the expense of long-winded declarations:

background-image: -webkit-linear-gradient(#fff, #000);
background-image: -moz-linear-gradient(#fff, #000);
background-image: -ms-linear-gradient(#fff, #000);
background-image: -o-linear-gradient(#fff, #000);
background-image: linear-gradient(#fff, #000);

It works well in theory but consider what happens in the wild:

1. Experimental properties are often implemented in the webkit engine first and there’s no guarantee they’ll be replicated in other browsers.
2. It’s often difficult to determine whether a vendor-prefixed property is part of the CSS specification. Some vendors don’t submit properties for standardization.
3. Even if the standard property changes, the incorrect vendor-prefixed version continues to be supported. Your old code still works; you won’t revisit it to correct the implementation.

You’ll often find sites using the -webkit prefixes alone — even if other browsers support the property or it has widespread availability without a prefix (such as border-radius). Chrome and Safari therefore look better than competing browsers — and the other vendors aren’t happy.

The issue was raised and discussed in the W3C meeting on February 7, 2012:

Web standards activists are teaching people to use webkit. You will see presentations from all the web standards advocates advocating people to use webkit prefixes.

Our job is to solve interoperability.

At this point we’re trying to figure out which and how many webkit prefix properties to actually implement support for in Mozilla.

If we don’t support webkit prefixes, we are locking ourselves out of parts of the mobile web.

Let that sink in for a moment.

Non-webkit browsers will support the -webkit prefix. That is the solution being considered by the W3C.

The idea is likely to fail miserably. Two or more implementations of the same webkit property won’t be compatible so developers won’t be able to use it anywhere. No one wins — including Apple and Google.

But I’m more concerned about the irreparable damage it’ll cause if the solution is successful. Once developers discover webkit prefixes working in Firefox, IE and Opera, they’ll expect them to work on all properties. Webkit-only adoption will rise exponentially and the vendors will be forced to implement the prefixes throughout. At that point, webkit properties will become the de facto standard regardless of any W3C specification. Game over: the open web is closed.

The implications also go further than CSS: many of the new JavaScript APIs have vendor prefixes.

Who’s to Blame?

We can point the sticky finger of failure at:

The W3C Working Group
It takes too long for web standards to reach maturity. That may be unavoidable but browser vendors are bypassing the process.

Browser Vendors
In their rush to push new technologies, it’s too easy for vendors to add a prefix and forget about it. Web developers require more information: is the property being considered by the W3C and when will the prefix be dropped?

In an ideal world, experimental prefixes would disappear once the browser implements the standard property. Vendors won’t do that because it’d break sites, but they could do more to highlight the problem, e.g. provide obsolescence detection tools or output error messages to the developer console.

Apple and Google
Both are guilty of promoting webkit prefixes as though they’re a standard part of day-to-day HTML5 web development. Apple has been accused of actively working against the W3C.

Mozilla, Microsoft and Opera
Other vendors are often months behind the webkit browsers — if not years. Adding webkit prefixes is a ludicrous solution: it’s time to up their game.

Technology Websites and Evangelists
We all love cool demonstrations but evangelists often neglect to mention that properties are experimental and may never have full browser support (and, yes, that includes SitePoint). Ideally, code should work in at least two browsers; at least it would indicate that multiple vendor prefixes are required.

Web Developers
We’re too lazy. We’re writing browser-specific code and, while we may have good intentions about correcting it later, we rarely do.

Do you recall the last time developers targeted a specific browser? It was IE6. We’re still living with the legacy of that decision a decade later. Do you really want history to repeat itself?

It’s Time to Act

I’m opposed to non-webkit browsers supporting webkit prefixes. At best, it makes prefixes unusable. At worst, it breaks the whole standardization process. You may agree or disagree but make your opinion known to colleagues, in blogs and on social networks. The W3C and browser vendors will listen to your feedback; you just need to provide some.

Then test your site in multiple browsers. A little graceful degradation is fine but neglecting one or more modern browsers with equivalent support is not. Fix the code, otherwise your site is contributing to the problem.

Frequently Asked Questions (FAQs) about CSS Prefixes and WebKit