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.
-moz-griddeclaration 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
griddeclaration eventually. This shows that namespace clashes may occur even with vendor prefixes.
filterdeclaration 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.
Upcoming speaking gigs: