Vendor prefixes: the good, the bad and the ugly

If you’re a forward-thinking web developer, you must be pretty familiar with code that looks something like this:

.foo {
-moz-transform: rotate(45deg);
-ms-transform: rotate(45deg);
-o-transform: rotate(45deg);
-webkit-transform: rotate(45deg);
}

The same property, repeated four times but with four different prefixes, one for each of the four main browser rendering engines (these are known as vendor prefixes). It seems wasteful; all four operate in exactly the same way, so all this means is extra work for us and a lot of repetition in our stylesheets. Unsurprisingly, a lot of people are calling for these prefixes to be scrapped. In a post which began a round of discussion recently, Henri Sivonen said:

I think vendor prefixes are hurting the Web. They are hurting Web authors. They are hurting users of browsers. They are hurting competition in the Web browser space.

This divided opinion. Daniel Glazman disagreed in a point-by-point rebuttal, but Alex Russell was more emphatic still, saying “vendor prefixes are a rousing success”:

Prefixes are an enabler in allowing the necessary process of use, iteration, and consensus building to take place.

So I’d like to provide a little context to the debate, as well as put my own opinion on the relative success of vendor prefixes.

What are vendor prefixes for?

In the past they were mainly used for features that were proprietary to each particular browser, but in recent years they’ve become more common as a way to introduce experimental support for new CSS properties, before they become standardised. The aim is that no browser introduces a new feature before it’s been found to be fully interoperable with other browsers.

As an extreme example, imagine we introduce a new property called dangle which takes a single angle value, like so:

.foo { dangle: 45deg; }

Seems straightforward, but what if WebKit measured that angle vertically, and Mozilla, horizontally? If the two implemented the property without a prefix, the feature would be interoperable; in one of the two browsers it would display completely differently to how you wanted it.

Browser prefixes are intended to save us from that problem, and when they do their job, they do it very well. For a real world example, consider the radial-gradient property. This is how the syntax looked when WebKit first introduced it, used to create a circular black to white gradient from the top left corner with a 100px radius:

gradient(radial,0,0,0,0,0,100,from(black),to(white);

Not to put too fine a point on it, it was ugly. As the syntax currently stands, you have to do this to get the same effect:

radial-gradient(0 0,circle,black,white 100px,transparent 100px);

But there’s a new, refined syntax on its way, which does the same like this:

radial-gradient(100px circle at 0 0,black,white);

The syntax has undergone radical changes since first being introduced, it’s much more logical and human-readable now, and it’s thanks only to the browser prefixes being used that we haven’t ended up with a load of incompatible properties across different browsers, causing us (and therefore our clients) no end of problems.

So you can see how prefixes are useful in this example, but the complaints tend to come when we have the opposite; as in my first example, where we have four properties working in exactly the same way, seemingly standardised but not available for us to use yet.

That’s down to the way the W3C works. Their criteria state that features are deemed to be experimental until the module they belong to has gained Candidate Recommendation status. This means the technical reviews have been completed and there are no outstanding objections, which are things we don’t always get to see; while it may appear to us that the feature is ready, there may be very good reasons why it isn’t.

The real problems with browser prefixes

Other than making our code messy and repetitious, there are two serious problems being caused by prefixes in the form they currently take.

The first is that developers love to experiment with cutting edge features as they’re released, creating demos to show off their potential. But sometimes a feature can be implemented in one browser years before it appears in others, as was the case with CSS Animations. When that happens, those demos aren’t always updated to accommodate the new vendor prefixed property, meaning that in new browser versions the demos simply don’t work even though it seems as if they should – which looks like the fault of the browser, not the developer.

The other problem occurs when developers use prefixed properties in a way that, deliberately or otherwise, means the targeted browser is the only one that can display the site correctly. I’m thinking specifically of WebKit properties on mobile here; it’s unfortunately the case that some developers make mobile websites using -webkit- properties only, meaning that alternative browsers – such as IE9 Mobile, Opera Mobile, Firefox for Android – get a broken or non-existent experience. This is an example where browser prefixes lead to a browser monoculture which is actively harmful.

The situation has become so bad that some browser makers have considered implementing -webkit- properties just so that their users can browse the web without problems. Should this happen, this would break the vendor prefix system once and for all.

Some proposed solutions

Many people have suggested ways to replace the vendor prefix system: Henri Sivonen suggested in his original post that experimental features should be kept in nightly and development releases of browsers, and not make their way into full releases until they are stable. Lea Verou suggested a number of different approaches, including using a single experimental prefix but applied per-browser using an @vendor rule, and Felipe Gomes has a similar suggestion, using the @vendor-unlock rule to activate experimental properties.

However, all of these people believe that the vendor prefix system is more fundamentally broken than I do. I think the problem is a little more obvious, as you’ll notice that both of the key problems I described previously have a clear commonality: developers. Us. As Opera’s Bruce Lawson said:

We’re approaching a monoculture on mobile. This is not the work of an evil organisation, but it’s developer-constructed.

In a post on this subject on my own blog, I argued that we need to take more responsibility, including:

  • Commit to supporting old demos that we have made.
  • Always make sure we plan our designs and builds in a way that they are not reliant on prefixed features, but degrade gracefully.
  • Don’t use an unprefixed property before standardisation has happened unless we can have reasonable confidence that it is safe.

Even if you’re an advocate for a more fundamental revamp, you should agree that a change in our behaviour could be massively beneficial to the web as a whole.

Of course, there is another option: don’t use vendor prefixed properties at all.

Bonus section: Tools

If you get bored writing out all of the prefixes individually, there are tools such as Prefixr and CSS3 Please! which allow you to write the rule once and have all the code output for you.

An alternative approach is to use tools which pre-process your stylesheets, either on the client side like -prefix-free or LESS, or the server side like Sass. Note that the former two introduce a dependency on JavaScript, which may be less than optimal.

Published by Peter Gasston

Peter Gasston has over ten years experience in front end development in both agency and corporate environments, working for and with some of Britain’s biggest media companies, and is currently the senior front-end developer at Top10.com. Peter is a public speaker, the author of The Book Of CSS3, and writes the well-respected blog about web technologies, Broken Links.

9 Comments So Far, what do you think?

  1. Henri Sivonen

    “Seems straightforward, but what if WebKit measured that angle vertically, and Mozilla, horizontally?”

    That can be solved by refraining from bikeshedding and sticking to the direction that was chosen by whoever shipped first.

    “radial-gradient”

    The CSS forward-compatible parsing rules already take care of dropping properties that have changed in a grammar-incompatible way, so prefixes aren’t needed in that case.

    “developers”

    I’ve been looking at the Web from the side of a bug database for a Web browser engine for over a decade. The browser-side perspective has convinced me that for each Web developer who has clue and who follows what’s going on, there aren’t like that. And even clueful developers do client projects that they don’t maintain forever if they don’t get paid forever.

    To solve the problem that vendor prefixing poses to browser competition, it makes sense to seek solutions that don’t rely on Web developers proactively changing their habits.

  2. Lea Verou

    That kinda sounds like telling a fat person they should go on a diet or a teenager to clean their room. It’s what everybody knows they should do, but nobody wants to do it. Your proposed solution is basically telling developers to “behave”?
    IMO when doing the right thing is becoming such a chore, it’s an indication that we need better approaches, not more self-discipline.
    If the right thing doesn’t come naturally to knowledgeable, smart, well-meaning people, the process is fundamentally flawed and needs to change.

  3. Peter Gasston

    I’m not closed to the idea of a change in the way experimental features work, but I’ve yet to see a genuinely compelling case that vendor prefixes don’t work when used correctly. The sad part of this story is that they’re not being used correctly at the moment.

    This morning the chair of the CSS Working Group, Daniel Glazman, issued an open call to all developers asking for them to immediately stop making sites aimed at WebKit only, and to fix the ones they already have: http://j.mp/yaEUDo

    The problem with all of the alternative proposals is that none of them solve the problem we have right now. This is a problem made by developers, and it needs to be solved by developers.

  4. Pingback:design for the web » Blog Archive » debating vendor prefixes

  5. Pingback:Are you developing for all browsers or just your favourite? | MSDN Blogs

  6. Pingback:Prefix your CSS automagically! | ISYS 353

  7. Pingback:Testing for website compatibility in Firefox on Android | Aaron Train

  8. Pingback:On Opera’s Implementation of WebKit Aliases - Broken Links

  9. Dennis

    I like your take on vendor prefixes, it’s close to my own. However, the reason corrective measures must be taken by the vendors and/or the W3C rather than the developers, is simply because the developers are individuals, not an organized entity. Getting group behavior instituted has proven impossible in the past, and is very unlikely going forward.

    Great article, Peter.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>