A year and a half ago, Eric wrote a great article in A List Apart called Prefix or Posthack. It’s a balanced look at vendor prefixes in CSS that concludes in their favour:
If the history of web standards has shown us anything, it’s that hacks will be necessary. By front-loading the hacks using vendor prefixes and enshrining them in the standards process, we can actually fix some of the potential problems with the process and possibly accelerate CSS development.
So the next time you find yourself grumbling about declaring the same thing four times, once for each browser, remember that the pain is temporary. It’s a little like a vaccine—the shot hurts now, true, but it’s really not that bad in comparison to the disease it prevents.
Henri disagrees. He wrote a post called Vendor Prefixes Are Hurting the Web:
In practice, vendor prefixes lead to a situation where Web author have to say the same thing in a different way to each browser. That’s the antithesis of having Web standards. Standards should enable authors to write to a standard and have it work in implementations from multiple vendors.
Daniel Glazman wrote a point-by-point rebuttal to Henri’s post called CSS vendor prefixes, an answer to Henri Sivonen that’s well worth a read. Alex also wrote a counter-argument to Henri’s post called Vendor Prefixes Are A Rousing Success that echoes some of the points Eric made in his ALA article:
The standards process needs to lag implementations, which means that we need spaces for implementations to lead in. CSS vendor prefixes are one of the few shining examples of this working in practice.
Alex’s co-worker Paul disagrees. He recently wrote Vendor Prefixes Are Not Developer-friendly:
- Prefixes are not developer-friendly.
- Recent features would have been in a much better state without prefixes.
- Implementor maneuverability is not hampered without prefixes.
All of this would have remained a fairly academic discussion but for a bombshell dropped by Tantek at a face-to-face meeting of the CSS Working Group in Paris:
At this point we’re trying to figure out which and how many
-webkit-prefix properties to actually implement support for in Mozilla.
The superficial issue is that web developers have been implementing -webkit- properties without then adding the non-prefixed standardised version (and without adding the corresponding prefixes of other vendors). The more fundamental problem is that while vendor prefixes were intended to introduce experimental features until those features became standardised, the reality is that the prefixed version ends up being supported in perpetuity. Nobody is happy about this situation but that’s the unfortunate reality.
Among the unhappy voices are:
- Bruce who wrote On the Vendor Prefixes Problem,
- Aaron who wrote This Must Not Happen!,
- Remy who wrote Vendor Prefixes — about to go south,
- Rachel who wrote a Call for action on Vendor Prefixes on the WaSP blog, and
- Daniel once more entered the fray, writing Call For Action: The Open Web Needs You Now.
Once again, Eric sought to bring clarity to the situation in the form of an article on A List Apart, this time publishing an interview with Tantek. Alex also popped up again, writing a post called Misdirection which addresses what he feels are some fundamental assumptions being made in the interview.
Finally, Mozilla engineer Robert O’Callahan—who I chatted with briefly at Kiwi Foo Camp about the vendor prefix situation—wrote about Alternatives To Supporting -webkit Prefixes In Other Engines in which he makes clear that evangelism efforts like Christian’s, while entirely laudable, aren’t a realistic solution to the problem.
It’s all a bit of a mess really, with lots of angry finger-pointing: at Apple, at Mozilla, at web developers, at the W3C…
My own feelings match those of Eric, who wrote:
I’d love to be proven wrong, but I have to assume the vendors will push ahead with this regardless. … I don’t mean to denigrate or undermine any of the efforts I mentioned before—they’re absolutely worth doing even if every non-WebKit browser starts supporting -webkit- properties next week. If nothing else, it will serve as evidence of your commitment to professional craftsmanship.