Call for action on vendor prefixes!

10 February 2012

Now that we have gotten to the point that we are almost rid of all the problems caused by IE6, we are about to go back to square one. Vendor prefixes, a necessary evil, seem to cause IE6-like-problems. We frontend developers have to stand up and do something!

Vendor prefix introduction (for noobs)

When yo are styling a website with CSS you could use new and experimental "effects". This new gadgets aren't part of the standards yet. This means that these new values haven't been thought out properly yet. For example:

border-radius: 10px

This says that an element has gets rounded corners with a diameter of 10 pixels. When it wasn't really clear what this effect should exactly look like and what the syntax should be, browsers were looking for ways to implement and experiment with these new effects. This was achieved with vendor prefixes. This is neccesary to allow developers to experiment with these new options and give feedback on this. For border-radius it looked like this:

-o-border-radius: 10px;
-moz-border-radius: 10px;
-webkit-border-radius: 10px;

And to ensure that your site in the future just keeps working you should also include the version without vendor prefix:

-o-border-radius: 10px;
-moz-border-radius: 10px;
-webkit-border-radius: 10px;
border-radius: 10px;

With that last line, which is very important, you ensure that your site keeps working when the browsergentlemen are done thinking and the vendor prefixs is no longer needed.

The problem?

Last monday Daniel Glazman wrote an article about the upcoming problem of non-webkit-browsers implementing -webkit-* prefixes to make sure webkit-only-websites will work in their browsers. A lot of webdevlopers use Chrome to develop their sites (including me) and only use the webkit prefix to achieve certain effects. Just like back in the days with IE6, a lot of websites only work in webkit browsers.

What could happen?

Two things could happen:
1. Non-webkit-browsers like Firefox and Internet Explorer implement -webkit-* prefixes to make sure webkit-only-websites still display correctly in these browsers. This way, an experimental browserspecific "hack" instantly becomes a standard. And we go back in time 10 years.
2. Non-webkit-browsers only support their own prefixes. All developers use all vendor prefixes ánd the futurproof version. The web is saved.

What should we do?

De solution is simple: we frontend developers should all just do our jobs. Part of our job is optimizing a website for all browsers. Therefor you should use ALL vendor prefixes AND the futureproof syntax. ALWAYS.

Do this in large projects, simple tryouts and fiddles, in personal projects, basically in everything you do. And the internet will be and stay a better place. If you don't do this we'll all go 10 years back in time, your job will become a hell and everything will be fucked...


I didn't want to go in deep on vendor prefixes as a concept, but if you'd like to learn more about this, there are lots of other blogs about this urgent subject:
You must have JavaScript enabled to use this form!

Leave a comment!

  1. Your mail is safe with me. It's only only used to display your Gravatar image!


  1. Gravatar

    Johan van Tongeren

    10 February 2012

    LESS (or anything like that) is a good sollution. Lea Verou's Prefixfree is also a good plugin to fix problems, but a lot of fiddles and small experiments are only made to work in webkit because it takes too much time to implement all other vendor prefixes or use such a library to fix these problems.

  2. Gravatar

    Max Keyner

    10 February 2012

    I use LESS for this issues, helps me a lot with this crap.