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.

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.

Newsletter

6 Comments
  1. Colin May 15, 3:16 am

    The term cross-browser compatibility makes me sick

    Reply
    0
  2. Andrew May 15, 4:11 am

    I agree with you Colin, they all use different standards because they are too lazy to get together and pick one that is universal and we are left to pickup the pieces.

    Reply
    0
  3. Stev Newbury May 15, 11:05 am

    It’s an interesting topic that I can’t see going away any time soon. Firefox and co implementing WebKit prefixes will not fix the problem, only make it more widespread. They are almost giving in!

    Some of the links you have included are interesting too – Lea’s piece of JS will certainly get a look in today!

    Great stuff Joe, thanks!

    Reply
    0
  4. Andrew Reynolds May 16, 7:29 am

    This is the thing that makes me want to walk into the development rooms of most browser vendors and do a falling down on them. I mean for a gradient i have to write a huge chunk of messy code! WTF! So I just reverted back to using the simple background image for a gradient. Sure i might add a few Kbs to the download BUT at least i don’t have to go through endless bloated mark up to change a gradient value and nor do i have to repeat it for several vendors.

    The same happens with most CSS3 properties! CSS3 has been great but you would think that by now vendors would all agree on friggen standards! I mean web dev is now so advanced we don’t face the issues of say 7 years ago in regards to web design so we dont need to prefix for each bloody vendor!

    Imagine if every TV station around the world had their own palette or their own standards that could not be viewed on a simple TV? Yes i know about PAL and NTSC in the video age..but really the rest of the world embraced PAL and only the americas had NTSC. But my point is in this day and age we should have a universal standard so content can be delivered and presented the same regardless!

    Reply
    0
    • Rochester May 16, 8:07 pm

      Nice point Andrew!

      That remind me those times when we had to write 2 or 3 CSS files to make things work well on IE5.5, IE6, Mozilla..

      Sometimes prefixes are pretty crazy indeed!

      []‘s

      Reply
      0
  5. cythux May 20, 10:33 pm

    For the most Site I support only for IE8 for Vista and 9 and newer, and the all the other browser.
    My first start i use a reset / normalize for the all browsers http://necolas.github.com/normalize.css/ and Moderizer. An other alternative are LESS or SASS/SCSS

    Reply
    0

Leave a Reply

*
* Minimum length: 20 characters