My goal with Polypane is improving the workflow for developers and designers. The main focus is of course developing an excellent browser for developers and designers, but I’m also developing online tools that help out during development. Two of them online now are a CSS specificity calculator, and a color contrast checker. Both of them […]
CSS Vendor prefixes considered important
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.