I'm writing a CSS book

JavaScript archives Compatibility Thidrekssaga QuirksBlog Donations CSS book Politics Mobile About COH

contact

Vendor prefix practicalities

I’ve been going through my CSS tests last week, and thought I’d jot down some notes on how the browser treat vendor prefixes. It’ll bring some much-needed practicality into the discussion.

This does not prove that vendor prefixes are either good or bad. It’s just one more data point to consider.

Let’s take a look at the theory first. This seems to be W3C’s official vendor prefix policy:

Prior to a specification reaching the Candidate Recommendation stage in the W3C process, all implementations of a CSS feature are considered experimental. The CSS Working Group recommends that implementations use a vendor-prefixed syntax for such features, including those in W3C Working Drafts. This avoids incompatibilities with future changes in the draft.

Once a specification reaches the Candidate Recommendation stage, non-experimental implementations are possible, and implementors should release an unprefixed implementation of any CR-level feature they can demonstrate to be correctly implemented according to spec.

That’s clear. Unfortunately it’s not what’s happening in practice.

• Transitions and animations are prefixed in all browsers, and the transition spec and animations spec are still in Working Draft. This fits the theory.
• All browsers have removed vendor prefixes from the Backgrounds module, which includes box-shadow and border-radius, even though the spec is only a Working Draft.
  Update: Seems this module actually was a CR, but went back to draft. Odd, but the browsers' actions are understandable now.
• All browsers but Firefox support an unprefixed box-sizing while the spec is only a Working Draft. I agree with the other browsers here for reasons I discuss below.
• The Multi-column Layout module is a candidate recommendation, but only IE and Opera have removed their column vendor prefixes. Those for Firefox and the WebKit browsers are still in place. It could be that they haven’t had the time yet to remove the prefixes, except the CR is from April 2011.
• Then there’s the curious case of selection styles. They’re prefixed in Firefox, but not in Opera and the WebKit browsers, and it seems they were removed from the spec (see 7.3). I’m not sure what happened here or how to fit this into the theory.
• Finally, the new Grid Layout has been implemented in IE10 only. Since this is new technology, Microsoft prefixed it. It turns out that there is also a -moz-grid declaration that is not an alternative implementation of grid layouts, but that has something to do with XUL. I assume Mozilla eventually wants to implement Grid Layout, so they’ll have to remove their old grid declaration eventually. This shows that namespace clashes may occur even with vendor prefixes.
  Recently IE dropped its proprietary filter declaration for much the same reason.

So the practical situation is a lot more muddled than theory suggests. I doubt that there’s one policy for vendor prefixes that’s tied to the recommendation’s status at W3C. Instead, it seems the browsers make up their own rules. Now I’m not against that; sometimes the browser vendors have a clearer idea of what’s going on than bureaucracy-bound W3C.

box-sizing is the clearest example here: vendor prefixes don’t make sense because implementations have stabilised. In fact, I have never seen any sort of browser difference whatsoever in the, I don’t know, seven or eight years I’ve been following this declaration. It’s either supported or not supported, and if it’s supported it allows you to specify whether width includes or excludes borders and padding. That’s it. So I feel Firefox is doing the wrong thing here.

I distinctly remember some sort of problem with border-radius a while back, but it seems it has been solved amicably by the browser vendors and the prefixes were removed — without the W3C issuing a Candidate Recommendation.

In any case, my point stands: browsers’ practical handling of vendor prefixes does not conform to W3C policy in the instances I quoted above. I don’t know how much of a problem that is, but it shows that the vendor prefix situation is more complicated than we (or at least, I) originally thought.