4 minutes

Vendor Prefixes: A Force For Good or Evil?


The Story and Problems

If you’re a web developer working with CSS (especially CSS3) in modern browsers, it’s more than likely that you’ve come across these things called vendor prefixes. Initially used for features unique to certain browsers, vendor prefixes are essentially a way of making a certain CSS property exclusive for one browser or rendering engine.

At face value, vendor prefixes seem like a nice idea. They allow for certain browsers to implement unique or experimental functionality, such as properties found in un-finished or un-standardized CSS specifications, and so should (at least in theory) be accelerating web and browser development. The guys who make the browsers (such as those over at Google and Mozilla) must be really excited about having their browsers on the cutting edge with experimental CSS3 implementations and whacky ideas here and there, however when trying to utilize vendor prefixed properties in practice, cracks begin to form.

The first thing that most developers notice when trying to implement modern CSS3 techniques into their websites to be utilized by newer browsers, is the mess that vendor prefixes create in their code. As different versions of different browsers understand different things, many different properties must be used to accomplish the same thing in multiple browsers. Take a simple CSS3 gradient for example – the CSS required to make a gradient that will work in most modern browsers usually looks something like this:

background-image: -webkit-gradient(linear, left top, left bottom, from(#444444), to(#999999));
background-image: -webkit-linear-gradient(top, #444444, #999999);
background-image: -moz-linear-gradient(top, #444444, #999999);
background-image: -ms-linear-gradient(top, #444444, #999999);
background-image: -o-linear-gradient(top, #444444, #999999);
background-image: linear-gradient(to bottom, #444444, #999999);

That’s five vendor prefixed properties, and then one actual ‘real’ CSS3 property for the browsers which are out of the ‘experimental phase’. It’s worth noting that in the code snippet above, two of the vendor prefixed properties are for webkit! This occurred because of a change in the experimental functionality that Chrome and Safari supported, and thus if all versions which could display the gradient are to be supported, both the old and new versions should be used. This kind of backwards compatibility could lead to big complications.

Not only is the code visually messy (It’s things like this that make me cry myself to sleep at night), but if the colours in the gradient need to be changed, twelve values need to be changed! It’s important to remember that if vendor prefixes weren’t used and browsers just went in and implemented experimental functionality, even more havoc would be created (let’s say that Chrome took the parameters in the opposite order to Firefox in its implementation), but is it really necessary to have to include all of these lines just for a gradient?

As if this doesn’t seem like a big enough problem in itself, things don’t get any better when developers get lazy. Some developers use some vendor prefixes and not others, creating inconsistencies between browsers that should really be displaying things in the same way. Even worse, some developers don’t create fallbacks for advanced properties! A solid background colour should be set as a fallback if gradients are not supported in the browser. Without any fallback, massive problems can be created with different websites in different browsers that support different things. A rounded corner turning square in older versions of Internet Explorer isn’t a big deal, but the main content division not having a background colour is! (Note: I’ve actually seen this in a production website!)

To make things worse, in recent drama it was thought that some web developers favorite the -webkit- (Chrome and Safari) vendor prefix. This didn’t leave the guys behind Firefox, Internet Explorer, and Opera too happy as it meant that some websites didn’t work as intended in their browsers. This led to them toying with the idea of implementing -webkit- prefixes in their browsers! Imagine the chaos and confusion that would be caused!

The situation with vendor prefixes is a huge mess, and whether it’s down to developer laziness (not including most prefixes or providing fallbacks) or the prefixes themselves, there is certainly a problem here.

Online HTML Email Template Builder

With Postcards you can create and edit email templates online without any coding skills! Includes more than 100 components to help you create custom emails templates faster than ever before. Try now for free!

Learn MoreOther Products

The Solutions

It’s all well and good talking and moaning about the pros and cons of vendor prefixes, but as with any debate, it ends up coming down to how we solve the problem or issue at hand.

Many solutions have been proposed, although none of them are perfect. Some people suggest that vendor prefix behavior should be completely removed from browsers and that we should wait it out until specifications become standardized, however I personally think this would hamper the growth of the web. This leaves the majority of solutions, which are essentially about fixing developer laziness.

Lea Verou has written an interesting piece of JavaScript called -prefix-free which prefixes un-prefixed properties in the CSS (It’s worth noting that Lea has also suggested a number of interesting solutions to the vendor prefix problem as a whole). The idea of JavaScript doing the prefix work for you is an interesting one, however it creates a dependency on JavaScript that makes it a sub-par solution for most work outside of tech and code demos. SASS and other CSS pre-processors can also solve the developer “laziness” problem by adding the prefixes in the compiling process, and this doesn’t introduce any extra dependencies either. The only real problem with using pre-processors as a solution is that by definitions, pre-processors require the code to be compiled – this makes the solution reasonably unappealing to those of us who don’t make use of CSS pre-processors.

A variety of tools and text-editor plugins have also been created to try and make it easier to prefix properties. These aren’t going to solve any vendor prefix crisis any time soon, but they are, at least for now, a developers best friend to writing prefixed properties. css3please.com is a brilliant resource and a great place to grab CSS3 properties and then change their values for your own personal usage, and there are also services like Prefixr and Lea Verou’s ‘CSS Gradients Please’ which can directly prefix code that you pass to it. A plugin for Sublime Text 2 called Sublime Prefixr has also been created so that code you write can easily be passed through the Prefixr API – giving easy access to a prefixed (and hence more rounded and generally more supported) version of your code. Very useful stuff.

Ultimately, it’s an interesting and complex issue. I personally think that vendor prefixes are here to stay in one form or another, and they do wonders for the growth of the web as a whole. It is certain however that something needs to be done to deal with the implementation issues. I think that for a short-term solution, websites like Prefixr make for a very nice way to prefix your code, however in the long term, the system needs some sort of change. A simple Google search should yield good results on what other people think of the vendor prefix situation, and if you have any opinions of your own, leave them in the comments section below – I’d love to hear what you have to say about the issue!

Joe Savage

Joe Savage is a budding developer, designer, and entrepreneur from the United Kingdom. As the owner of Dev-HQ.net, he helps people around the world get into the web development niche, and enjoys spending time raising awareness on certain issues through content creation and social media.

Posts by Joe Savage
Cookie Icon
We use cookies to ensure that we give you the best experience on our website.
  • I disagree
  • I agree