The Impending CSS Vendor Prefix Catastrophe

Share this article

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

What is the purpose of CSS prefixes like -moz-, -o-, -ms-, and -webkit-?

CSS prefixes, also known as vendor prefixes, are a way for browser makers to add new CSS features before they become part of the W3C (World Wide Web Consortium) standard. These prefixes ensure that the new features will only work in their browsers. For example, -moz- is for Mozilla Firefox, -o- is for Opera, -ms- is for Microsoft Internet Explorer and Edge, and -webkit- is for browsers using the WebKit engine like Safari and older versions of Chrome.

What is the WebKit prefix crisis?

The WebKit prefix crisis refers to the situation where non-WebKit browsers started supporting -webkit- prefixes to ensure compatibility with websites that only used these prefixes. This led to a fragmentation of the web standards and made it harder for new browsers to enter the market.

How can I use CSS prefixes in my code?

To use CSS prefixes, you simply add them before the CSS property in your stylesheet. For example, to use the border-radius property with vendor prefixes, you would write:

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

Are CSS prefixes still necessary?

While CSS prefixes were once necessary for cross-browser compatibility, they are becoming less important as browsers increasingly support the same standards. However, they can still be useful for using experimental features or ensuring compatibility with older browsers.

What is the role of W3C in relation to CSS prefixes?

The W3C, or World Wide Web Consortium, is the international standards organization for the World Wide Web. They are responsible for developing and maintaining web standards, including CSS. When a new CSS feature is proposed, it often starts as a vendor-prefixed feature. Once the feature has been thoroughly tested and agreed upon, it can become part of the W3C standard and the vendor prefix is no longer needed.

What is the impact of vendor prefixes on web development?

Vendor prefixes can make web development more complex, as developers need to include multiple versions of the same CSS property to ensure compatibility across different browsers. However, they also allow developers to use new features before they are officially standardized.

How can I ensure my website is compatible with all browsers?

To ensure your website is compatible with all browsers, you should use vendor prefixes for any CSS properties that require them. You can also use tools like Autoprefixer, which automatically add the necessary prefixes to your CSS.

What is the difference between -webkit- and other CSS prefixes?

The -webkit- prefix is used for CSS properties that are specific to browsers using the WebKit engine, such as Safari and older versions of Chrome. Other prefixes like -moz-, -o-, and -ms- are used for Mozilla Firefox, Opera, and Microsoft browsers respectively.

What are some common CSS properties that require vendor prefixes?

Some common CSS properties that often require vendor prefixes include border-radius, box-shadow, transition, transform, and animation. However, the need for prefixes can vary depending on the specific property and browser support.

How can I keep up with changes in CSS prefixes and web standards?

To keep up with changes in CSS prefixes and web standards, you can follow the updates from the W3C, browser vendors, and web development communities. There are also online resources like Can I Use, which provide up-to-date information on browser support for different CSS features.

Craig BucklerCraig Buckler
View Author

Craig is a freelance UK web consultant who built his first page for IE2.0 in 1995. Since that time he's been advocating standards, accessibility, and best-practice HTML5 techniques. He's created enterprise specifications, websites and online applications for companies and organisations including the UK Parliament, the European Parliament, the Department of Energy & Climate Change, Microsoft, and more. He's written more than 1,000 articles for SitePoint and you can find him @craigbuckler.

browserCSSCSS3HTML5 Dev Centerstandardsvendor prefixesw3c
Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week