Kilian Valkhof

Building tools that make developers awesome.

CSS Vendor prefixes considered important

CSS & HTML, 5 May 2010, 2 minute read

Lately, there has been a lot of hate towards vendor prefixes. First, PPK wrote about them, and then a some other people did. The proposed solution to the ‘problem’ of vendor prefixes is to get rid of them in favor of one -beta- prefix. Simply put: That won’t work.

Why they exist

You see, vendor prefixes exist for one important reason. Vendor prefixes are used for unfinished specifications. Unfinished specifications change. They evolve. Sometimes they don’t describe the implementation at all, or the syntax has yet to be agreed upon. They are not done yet. They are unfinished.

This means browsers could, and will implement things differently. To give a concrete example: Gecko and Webkit implemented the border-radius syntax differently. Had there been only one “-beta-” prefix, you could not have used border-radius in a cross browser way. That doesn’t seem like a real solution, does it?

But I have to type so much!

Sure, typing -moz-, -webkit, -o- again and again gets annoying, but come on, you’re a developer. It’s trivial to make a snippet (or whatever your editor calls them) for this, or to use a Sass or LESS mixin. Tools will save us.

Vendor prefixes are awesome

Vendor prefixes allow us to test out new technologies, they allow different browsers to implement them in the way they seem most conforming to the specification (at that moment). This in turn allows developers to deal with browser differences by setting different values for each vendor prefix.

Browsers get to test out different implementations, and developers get early access to new possibilities. That seems like an excellent deal to me.

Polypane browser for responsive web development and design Hi, I'm Kilian. I make Polypane, the browser for responsive web development and design. If you're reading this site, that's probably interesting to you. Try it out!

  1. Completely agree. Nothing else to add unfortunately, you summed it up nicely.

  2. It is not about that we are lazy developers or designers it is about the respecting the standards. The risk is that every browser will implement different syntax and we will have CSS for Firefox, CSS for Safari CSS for IE …

    So we will have official standard one day plus the different code for every browser. That is not just ugly code but also larger file size(slower page load). Do you really want to learn different CSS for every browser?

    Sass or LESS are great tools but the generated code will be always the same. Not to mention there are some people know just HTML, CSS and little Java Script.

    CSS should be easy and clean for everyone.

  3. […] Read more at → […]

  4. I disagree. If we are working towards a standard, there has to be one implementation of the standard. Otherwise, we land up exactly where we are today in web development – each browser doing their own thing. Instead of trying to fix it with HTML5, we’re advocating the different implementations specific to each browser which is the wrong way to go.

    Imagine if each browser implemented the tag differently. Would there be any sanity left?

    Also, as a side point, it’s not so much a bother typing 4 different declarations of setting border-radius, but it is 4x code size which is 4x slower.

  5. It’s text.

    It’s experimental, aiming towards a standard.

    FFS, it’s text. Are you *really* concerned about the modem user accessing your website? Really? Cut down on something other than a couple extra bytes of CSS code.

    There *is* no current standard for CSS3. If we didn’t have these vendor prefixes, we *wouldn’t* have any CSS3 access. Period. Nuff said?

  6. dustin

    Dead wrong. If there needs to be a standards, then that requires one code base and not one for each browser. I don’t care if its experimental or still in development. Why do it one wrong way up until the end then suddenly change it? That risks bugs, slowed development time, and other issues. Its like painting a room blue before painting it the read color you want it, red. That just wastes time and effort.

    Its nice that we have the options to use browser prefixes, but there shouldn’t be any to begin with! We’re making a standard that involves FOUR sets of code here people!

  7. Completely agree. For the commenters who say we ought to have only one behavior for one property — that’s exactly the point. It would be far worse for each browser to jump straight to the non-prefixed, standard property, and then discover after the fact that they did it wrong or incomplete. Then we would have different browsers doing multiple things on one single property, and that royally sucks. That’s where we got all those horrible IE and Netscape hacks from. Let’s not go there again.

    Prefixes give browsers and developers the chance to test out the specification in the wild, so they can not only change the individual browser’s behavior but also the spec. The problems with a spec never become clear until the properties have been used extensively in real sites. This doesn’t mean we have to use the browser-specific properties on client work, but a good portion of people do need to use them on personal projects at least to really put them through the wringer. It’s a much safer way of ensuring that we all get to the consistent browser rendering of a single standard that we want.