CSS vendor prefixes considered harmful

I recently came across a post about border-radius by the IE team, that said IE9 supports border-radius (cool!) without vendor prefix (even cooler!)

The post continues:

While a number of web pages already make use of this feature, some [...] do not render properly in IE9 or Opera 10.50 because they lack an unprefixed declaration of the border-radius property. As the specification nears Recommendation and browser vendors are working on their final implementations and testcases for submission to the W3C, we recommend that new content always include a border-radius declaration without vendor prefix.

I’d like to go one step further.

It’s time to abolish all vendor prefixes. They’ve become solutions for which there is no problem, and they are actively harming web standards.

Vendor prefixes force web developers to make their style sheets much more verbose than is necessary, while also running the risk of accidentally forgetting one set of vendor-prefixed declarations.

Besides, why do we need to use several declarations for obtaining one single effect? Weren’t web standards supposed to prevent that sort of thing?

Guys, let’s stop the vendor prefix nonsense. Enough’s enough.

Update: Although the problem is real, my solution is not the best one possible. See the redux for more discussion.

The point

Originally, the point of vendor prefixes was to allow browser makers to start supporting experimental CSS declarations.

Let’s say a W3C working group is discussing a grid declaration (which, incidentally, wouldn’t be such a bad idea). Let’s furthermore say that some people create a draft specification, but others disagree with some of the details. As we know, this process may take ages.

Let’s furthermore say that Microsoft as an experiment decides to implement the proposed grid . At this point in time, Microsoft cannot be certain that the specification will not change. Therefore, instead of adding grid to its CSS, it adds -ms-grid .

The vendor prefix kind of says “this is the Microsoft interpretation of an ongoing proposal.” Thus, if the final definition of grid is different, Microsoft can add a new CSS property grid without breaking pages that depend on -ms-grid

Now in itself this is a reasonable line of thought. Point is, it’s outlived its usefulness. It’s just not necessary any more, neither from a practical nor from a more philosophical point of view.

Practical problems

Let’s take a look at some practical cases.

box-sizing

One place where vendor prefixes have always annoyed me terribly is the box-sizing property that allows you to switch from one box model to another. Currently IE8 and Opera support box-sizing without prefix, but Firefox supports only -moz-box-sizing and Safari, Chrome, and all mobile WebKits only -webkit-box-sizing .

In other words, this is the code to switch the box model of one div.

div.borderbox { box-sizing: border-box; /* one */ -moz-box-sizing: border-box; /* two */ -webkit-box-sizing: border-box; /* three */ }

The fact that I have to use three declarations for obtaining one effect is completely preposterous. We might as well live in the Browser Wars era. Standards, anyone?

The point here is that box-sizing will not change any more. Its purpose is to switch box models, and its two values border-box and content-box are supported everywhere.

This declaration makes sense as it is, and it is supported by all browsers as it is. So it should have the same name in every browser.

Why wait for W3C to put its stamp of approval on it before removing the prefixes? We all know that’s going to take another five to ten years.

Mozilla, WebKit, you’re just being thoughtlessly conservative here. Get rid of your vendor prefixes.

Transitions

Consider the transitions Safari added. They’re all prefixed with -webkit- . Here, too, the point is that the Safari team has effectively specified all these declarations. They’re not going to change any more.

Google and Opera are implementing transitions, too. I studied the Apple and Opera documentations a bit, and they look quite alike. In fact, right now I dare state that Opera is working to copy Apple’s transitions system.

But Apple uses -webkit-transition , while Opera is using -o-transition .

Guys ...

div.coolEffect { -webkit-transition-property: opacity; /* one */ -webkit-transition-duration: 2s; -o-transition-property: opacity; /* two */ -o-transition-duration: 2s; -moz-transition-property: opacity; /* three */ -moz-transition-duration: 2s; -ms-transition-property: opacity; /* four */ -ms-transition-duration: 2s; }

I don’t want to use four browser-specific declarations to obtain one effect! This sort of vendor-specific nonsense is exactly what web standards were supposed to do away with. No more bloody fragmentation!

What if a web developer accidentally forgets one vendor prefix? Then the effect won’t work while it could — something we’ve learned to recognise as a grave sin. Still, it’s bound to happen in a standardless world.

Enough’s enough. Vendor prefixes have to go.

A peek into the future

The most idiotic example comes from the mobile world. Opera has implemented a touchscreen media query in the Vodafone widget manager, and called it -o-touchscreen .

When Samsung started to work on its WebKit-based widget manager, it was notified of the existence of this media query and promptly copied it. To the letter.

Thus, we now have a WebKit browser reacting to -o-touchscreen .

And this is just the beginning. It’s going to get much, much worse.

Eventually Opera will discover that plenty of sites use -webkit-transition , but not -o-transition . Will Opera start to support -webkit-transition , too?

From a compatibility perspective that might make sense. From any other perspective it’s totally ridiculous, though. And there’s a simple solution to this problem: transition has become a de-facto web standard. So treat it as one.

Let’s stop the vendor prefix nonsense. Now.

Philosophical problems

So from a practical perspective vendor prefixes are turning into a tool for fragmentation. From a philosophical perspective, moreover, they solve problems that just aren’t there any more.

As far as I can see vendor prefixes were supposed to solve two problems:

The problem with unfinished standards I outlined earlier. The problem underlying that problem: an automatic assumption that, when left to their own devices, browser vendors would all start to implement their own stuff without paying attention to what the other browsers were doing.

Both problems have meanwhile been solved, as far as I can see.

We’re currently moving toward a situation in which anything that is implemented by two browsers more-or-less automatically becomes a standard. I don’t think that this change of process has been accepted by W3C yet (it might take another generation), but it’s becoming reality as we speak.

The reason this system can work is because browser vendors now want to copy each other’s implementations! Microsoft, Mozilla, Apple, Google, and Opera are all eyeing each other’s browsers and want to resemble each other in standards support, while competing in execution excellence, interface smoothness, and standards extension.

Contrary to the Browser Wars era when vendor prefixes were defined, right now browser vendors are genuinely interested in interoperability. There is no danger any of them will go off on a wild tangent and, I don’t know, redefine box-sizing: border-box to mean “anything inside the border.” That sort of thing just doesn’t make sense any more today.

The Safari team invented cool, new transition stuff. They made it CSS-based, documented it, and submitted it to W3C. That’s all good.

Then they added the -webkit- prefix. That’s bad.

Now Opera comes along, and wants to support transitions, too. Is Opera going to invent its own system? Is Opera suddenly going to give transition a completely different meaning that is totally incompatible with Safari’s?

Of course not! The Opera guys aren’t crazy. They know their bread is buttered on the compatibility side of things. The same goes for all other browser vendors.

But they do add their own vendor prefix. That’s ridiculous. And pointless.

transition and all the rest have become de-facto standards. Any browser implementing the transition system will make sure that it is compatible with Safari. So who needs vendor prefixes?

Dear browser vendors, take a little more pride in your willingness to work with your competitors towards web standards, even when you invent new functionality. You do not need vendor prefixes any more. You’ve grown beyond them.

The time has come to abolish all vendor prefixes. They’ve become fossils of a bygone era, but with the potential to harm web standards significantly.

Update: Although the problem is real, my solution is not the best one possible. See the redux for more discussion.

Comments are closed.