7 Solutions to the CSS3 Vendor Prefix Crisis

Share this article

Key Takeaways

  • The CSS3 Vendor Prefix crisis is a significant issue in web development, with browsers such as Mozilla, Microsoft, and Opera frustrated by sites only targeting -webkit CSS3 properties. Various solutions have been proposed, including non-webkit browsers supporting the webkit prefix, all browsers using a -beta prefix, and experimental CSS properties only appearing in beta browsers.
  • Other potential solutions to the crisis include dropping vendor prefixes following final implementation, accelerating the W3C agreement process, and fostering better evangelism and education in the developer community. Each solution has its pros and cons, and there’s no one-size-fits-all solution.
  • Ultimately, the author suggests that the issue was caused by developers and it’s their responsibility to fix it. There won’t be a problem if developers avoid prefixed properties or use correct cross-browser fallbacks. Otherwise, there’s a risk that the CSS3 properties currently relied upon may not work in the future.
As we reported last week Mozilla, Microsoft and Opera have become frustrated with sites which only target -webkit CSS3 properties. It makes their browser look bad even when it implements identical or better technology. To solve the issue, they propose adding -webkit prefix support to the non-webkit browsers. While this is largely a marketing decision, it’s a real problem. The solution appalls many web developers but we deserve our share of the blame. In this article we’ll discuss the options, pros and cons.

1. Nothing Changes

Assume nothing is done to solve the browser prefix problem. PROS
  • Browsers continue to implement their own prefixes which you are free to use or ignore.
  • There’s nothing new to learn or test.
  • It feels right and the decision will please the majority of web developers.
CONS
  • We retain the four prefixed and one standard property. Stylesheets are larger than necessary and difficult to test.
  • Lazier or less experienced developers will continue to target webkit browsers only.
  • Chrome and Safari’s market share could rise to a point which makes other browsers redundant. We return to the days of single browser engine and innovation stagnates. The dark days of IE6-like dominance return.
  • Microsoft, Mozilla and Opera consider this to be a real problem: doing nothing is not an option.

2. Non-Webkit Browsers Support the Webkit Prefix

Assume IE, Firefox and Opera support webkit-prefixed properties. Microsoft had already implemented -webkit-text-size-adjust in the mobile version of IE. While it’s a non-standard property for Safari (there’s no text-size-adjust), they listened to community feedback and pulled support. That’s unlikely to happen again if Mozilla or Opera start adding webkit properties to their engines. PROS
  • It’s a quick and dirty solution which allows non-webkit browsers to render as well as Chrome or Safari.
  • There’s no need for developers to update their websites.
  • -webkit will become the dominant prefix; using -moz, -ms or -o will become unnecessary and CSS file sizes will reduce
  • It prevents webkit, Google and Apple becoming too powerful. If another vendor disagrees with an implementation, they can simply break it or provide an alternative. Developers may not be able to use the property in any browser.
CONS
  • It feels wrong: one browser should not need to masquerade as another.
  • It rewards sloppy development practices.
  • Differing browser implementations will make some properties unusable.
  • If developers retain webkit properties which fail in other browsers, more users will switch to Chrome and Safari. Other vendors will become increasingly irrelevant.

3. All Browsers Use a -beta Prefix

Rather than separate prefixes, assume every browser implemented the same -beta prefix. PROS
  • Just one prefix to learn and use.
  • Stylesheet file sizes are reduced.
  • The property is obviously experimental; developers will be more cautious about using it.
CONS
  • As a solution, it’s little different to every vendor adopting the -webkit prefix.
  • Differing browser implementations may make some properties unusable.
  • Vendors are unlikely to remove their own prefixes; the situation won’t change.

4. Experimental CSS Properties Only Appear in Beta Browsers

Assume prefixed properties are abolished in all browsers. Newer experimental properties would only be present in nightly and beta releases — and they would not require a prefix. PROS
  • It becomes impossible for developers to use prefixed code or target specific browsers in production websites.
  • Webkit-only sites are punished accordingly.
  • We all work to final standards — not future ones.
CONS
  • Far fewer developers will use and test experimental properties. It could lead to buggier implementations.
  • New properties may take several years to become standardized. Are we prepared to wait?
  • It’ll never happen. If a single vendor chooses to keep prefixes in their main release, they all will.

5. Vendor Prefixes are Dropped Following Final Implementation

Once a property is stable and implemented without a prefix, all previous prefixed versions are removed from the browser. PROS
  • It’s a logical solution.
  • It removes unnecessary code. Library bloat is reduced and browsers become leaner and faster.
  • It rewards good development practices and punishes the bad.
CONS
  • It offers no immediate resolution for sites which only target webkit browsers.
  • It will break sites overnight — vendors will be reluctant to implement the policy.
  • Properties can take years to reach standardization and browser implementation schedules differ. Prefixes will break at different times so ongoing site testing and maintenance is required.

6. The W3C Agreement Process Becomes Faster

Assume the W3C adopt quicker methods of standardization and publish schedules detailing when a property is expected to reach maturity. PROS
  • The existing process is too slow.
  • Developers will know when the final property can be used.
  • There’s less chance for vendor prefixes to gain widespread adoption.
CONS
  • The process is not intentionally slow. There will always be practical and logistical problems to overcome.
  • Vendors work at different speeds and it’s impossible to accurately estimate delivery times.
  • A faster approval process could lead to poorer implementations which negates the point of having a standardization process.

7. Better Evangelism and More Education in the Developer Community

We would not be in this mess if developers wrote cross-browser code and understood best-practice techniques. PROS
  • It’s a good solution which we can implement today.
  • Anyone demonstrating example code with prefixed properties can provide browser support information with strong disclaimers.
  • Everyone can help. Fix your own code and contact sites which are not cross-browser compatible.
CONS
  • There’s no guarantee evangelists and developers will change their attitude.
  • Is it too late? Best-practice techniques are published but ignored.
  • There’s no definitive central information repository.
  • There will always be new, ignorant and sloppy developers. No one can become an expert overnight.
There’s no single solution to the vendor prefix problem. Personally, I favor a quicker W3C process, dropping prefixes after implementation and better evangelism. But those require a major shift in mindset rather than technical changes. Ultimately, developers caused this problem: it’s up to us to fix it. There won’t be an issue if we shun prefixed properties or use correct cross-browser fallbacks. If we don’t, there’s a risk the CSS3 properties we rely on today won’t work tomorrow.

Frequently Asked Questions (FAQs) about CSS3 Vendor Prefixes

What are CSS3 Vendor Prefixes and why are they important?

CSS3 Vendor Prefixes are a way for browser makers to add new CSS features to their browsers before these features become part of the official CSS standards. They are important because they allow developers to use new CSS features in a way that’s compatible with older browsers. This ensures that websites and web applications can still function properly even if users are using older browsers.

How do I use CSS3 Vendor Prefixes?

To use CSS3 Vendor Prefixes, you simply add the prefix to the beginning of the CSS property. For example, to use the border-radius property with a vendor prefix for Firefox, you would write it as -moz-border-radius. Similarly, for Chrome and Safari, you would use -webkit-border-radius.

How can I remove all vendor prefixes from my CSS file quickly?

There are several tools available that can help you remove all vendor prefixes from your CSS file quickly. One such tool is Autoprefixer, a post-processor for CSS. Autoprefixer uses data from Can I Use to determine which CSS properties need vendor prefixes.

What are some common vendor prefixes?

Some common vendor prefixes include -webkit- for Chrome and Safari, -moz- for Firefox, -o- for Opera, and -ms- for Internet Explorer and Microsoft Edge.

Are vendor prefixes still necessary?

The necessity of vendor prefixes has decreased over time as browsers have become more standardized. However, they can still be useful for ensuring compatibility with older browsers.

How can I find and remove vendor prefixes in my CSS using regex?

You can use regular expressions (regex) to find and remove vendor prefixes in your CSS. For example, the regex /^-moz-|^-webkit-|^-ms-|^-o-/ can be used to match any line that starts with a vendor prefix.

What is the impact of vendor prefixes on CSS compatibility?

Vendor prefixes can greatly improve CSS compatibility across different browsers. However, they can also lead to clutter and redundancy in your CSS code, especially if you’re using many different vendor prefixes.

What are some solutions to the vendor prefix crisis?

Some solutions to the vendor prefix crisis include using tools like Autoprefixer to automatically add and remove vendor prefixes, and using feature detection libraries like Modernizr to determine whether a specific CSS feature is supported in the user’s browser.

How can I keep up with changes in vendor prefixes?

You can keep up with changes in vendor prefixes by regularly checking the documentation of the browsers you’re targeting, and by using tools like Autoprefixer that automatically update your CSS code based on the latest browser data.

What are some best practices for using vendor prefixes?

Some best practices for using vendor prefixes include using them sparingly, always including the unprefixed version of the CSS property, and testing your CSS code in multiple browsers to ensure compatibility.

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.

applebrowsersCSSCSS3Google Tutorials & ArticlesHTML5 Dev CentermicrosoftMozillaoperavendor prefix
Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week