It’s Time to Rethink Vendor Prefixes in CSS

Share this article

The -webkit- prefix is now so dominant across CSS on the web that some websites fail to work properly without it. While this is clearly a sign of less than ideal practices by developers over the past few years, it has led to quite an unfortunate but almost necessary move by Mozilla. By either Firefox 46 or 47 (released either in April or May 2016), Mozilla plan to implement support for a series of non-standard -webkit- prefixes to improve Firefox’s compatibility with a -webkit prefixed (and often mobile) web.

This is not a new idea, Microsoft Edge supports a series of -webkit- prefixes too to ensure compatibility. Opera already began implementing -webkit- prefixes in 2012 and have since moved to the WebKit based Blink engine.

The W3C and browser vendors did not intend for vendor prefixes to be used on production websites:

“Official W3C policy states that you shouldn’t really use experimental properties in production code, but people do, as they want to make sites look cool and keep on the cutting edge.” – W3C page on optimizing content for different browsers
However, developers everywhere wanted to use them to access the latest features as soon as they could. While prefixes have caused a bit of a mess with WebKit’s dominance, I think they succeeded in helping the web move forward quite rapidly.

The approach by Mozilla and Microsoft is likely to be harmless to most websites. Most websites online will have already included -moz- prefixes or will find that the updates by Mozilla improve their website compatibility with no action required. As professional web developers though, we do need to be thorough and understand that there are outlier results that may occur on some designs. You may already know which of your creations could break with this update.

Developers, it is clearly time to rethink your approach to prefixes and test those websites.

The Prefixes Involved

There are a range of -webkit- prefixes Mozilla might look to include. From what I’ve gathered, Mozilla aren’t looking to match Edge’s list of supported -webkit- prefixes, as not all of these are likely to be necessary to ensure Mozilla’s Gecko layout engine compatibility with the broader web.

The prefixes Mozilla is likely to approach according to their wiki page on Compatibility/Mobile/Non Standard Compatibility includes the following:

  • -webkit-flexbox
  • -webkit- prefixed gradients
  • -webkit-transforms
  • -webkit-transitions
  • -webkit-appearance
  • -webkit-background-clip
  • -webkit-device-pixel-ratio
  • -webkit-animation
  • -webkit-border*

Some other features may be impacted too such as @-webkit-keyframes.

Cross Browser Testing Will Be Crucial

If you are a web developer out there who left out -moz- prefixes to avoid the need to test newer CSS features on Firefox — let’s assume you were on a tight deadline and the client forced your hand — you are going to need to retest that site in Firefox 46 or 47. These versions of Firefox will be out in either in April or May, so you have a bit of time to plan ahead.

To test your website before these changes reach Firefox 46/47, you can access the current state of the change in Firefox Nightly via the layout.css.prefixes.webkit preference in about:config. It should be set to true by default if you have the latest Nightly version installed. Not all of the -webkit- prefix changes are in Firefox Nightly just yet, however this is the place to test how your website looks so far. I would wait until about March before testing with Firefox Nightly too thoroughly.

On a more urgent note, Microsoft Edge is already interpreting and displaying -webkit- prefixes in this way. This means that any WebKit specific styles you have within your sites could already be displaying in a browser you were not expecting them to. If you have not already done so, get yourself access to Microsoft Edge in Windows 10 and test those websites!

Vendor Prefixes Are Fading

Luckily, it appears vendor prefixes are fading away as browser teams look for better solutions. The Chrome/Blink team have adjusted their approach:

“Going forward, instead of enabling a feature by default with a vendor prefix, we will instead keep the (unprefixed) feature behind the “enable experimental web platform features” flag in about:flags until the feature is ready to be enabled by default.” – The Chrome/Blink team

The Firefox team are also on their way to a similar approach:

“For what it’s worth, the current trend inside Mozilla is […] avoiding vendor prefixes by either turning things off before shipping or shipping them unprefixed if they’re stable enough. At least as a general policy; specific cases might merit exceptions.” – Boris from Mozilla

Microsoft Edge aims to remove support for prefixes altogether:

“Microsoft is also getting rid [of] vendor prefixes for Edge. This means that in order for developers to take advantage of special HTML5 or CSS features, they won’t have to use a specific Edge prefix. Instead, they can just code to web standards.” – Mashable

No More Graceful Degradation By Prefixes

This movement away from vendor prefixes means one thing — graceful degradation via vendor prefixing is clearly not the way to go.

Using vendor prefixes to target a specific browser (e.g. something specific just for Chrome) was not the intention of vendor prefixing; the recommendation was always for developers to use all available vendor prefixes (from -webkit- to -o-). If you are using features that rely on prefixed properties and you used prefixes to gracefully degrade your design on other browsers, this won’t work anymore.

Conclusion

The times are changing. WebKit’s dominance is unintentionally causing a fractured and incompatible web and other browsers are looking to expand their compatibility by implementing -webkit- prefixes to keep up. While this issue should fade as vendor prefixes are phased out, developers need to check that their use of prefixes does not cause unexpected results in non-WebKit browsers.

Frequently Asked Questions about Vendor Prefixes in CSS

What are vendor prefixes in CSS and why are they used?

Vendor prefixes are a way for browser makers to add new CSS features before they become part of the official CSS specifications. They are used to ensure that these new features will not interfere with existing features in other browsers. This allows developers to experiment with new features and provide feedback to the CSS specification process.

Are vendor prefixes still necessary in modern web development?

The necessity of vendor prefixes has been a topic of debate among web developers. While they were once essential for ensuring cross-browser compatibility, the modern web has seen a significant standardization of CSS features across different browsers. Therefore, the need for vendor prefixes has greatly diminished, but they are still used in some cases for experimental features.

What are some common vendor prefixes?

Some common vendor prefixes include -webkit- (Chrome, Safari, newer versions of Opera), -moz- (Firefox), -o- (Old, pre-WebKit, versions of Opera), and -ms- (Internet Explorer and Microsoft Edge).

How can I use vendor prefixes in my CSS code?

To use a vendor prefix, you simply add it before the CSS property in your stylesheet. For example, to use the border-radius property with a vendor prefix for Firefox, you would write -moz-border-radius: 10px;.

What are the drawbacks of using vendor prefixes?

The main drawback of using vendor prefixes is that they can make your CSS code more complex and harder to maintain. Each browser has its own vendor prefix, so you may need to write multiple lines of code for a single CSS property. Additionally, vendor prefixes can cause issues with code validation, as they are not part of the official CSS specifications.

How can I avoid issues with vendor prefixes?

One way to avoid issues with vendor prefixes is to use a CSS preprocessor like Sass or Less, which can automatically add vendor prefixes to your code. Another option is to use a post-processor like Autoprefixer, which can add vendor prefixes based on the browsers you want to support.

Are there any alternatives to using vendor prefixes?

Yes, there are alternatives to using vendor prefixes. One alternative is to use feature detection libraries like Modernizr, which allow you to test for specific CSS features and provide fallbacks for browsers that do not support them. Another alternative is to use CSS Grid or Flexbox, which are now widely supported and do not require vendor prefixes.

What is the future of vendor prefixes in CSS?

The future of vendor prefixes in CSS is uncertain. While they are still used in some cases, the trend is towards standardization and the use of feature detection instead of vendor prefixes. However, they are likely to remain a part of the CSS landscape for the foreseeable future.

How do vendor prefixes affect website performance?

Vendor prefixes can potentially affect website performance, as they can increase the size of your CSS code. However, the impact is usually minimal, especially if you are using a CSS minifier to compress your code.

How can I stay updated on the latest developments regarding vendor prefixes?

Staying updated on the latest developments regarding vendor prefixes can be challenging, given the rapidly changing nature of web development. However, following CSS-related blogs, forums, and social media accounts can help. Additionally, the CSS Working Group’s website and the Mozilla Developer Network are excellent resources for staying informed.

Patrick CatanzaritiPatrick Catanzariti
View Author

PatCat is the founder of Dev Diner, a site that explores developing for emerging tech such as virtual and augmented reality, the Internet of Things, artificial intelligence and wearables. He is a SitePoint contributing editor for emerging tech, an instructor at SitePoint Premium and O'Reilly, a Meta Pioneer and freelance developer who loves every opportunity to tinker with something new in a tech demo.

CSScss3 prefixesLouisLpatrickcvendor prefixvendor prefixes
Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week