Whose prefix is it anyway?
It looks like there is a little bit of a panic about CSS -pre-fixes. Well, that’s just though. It’s a little late to start bitching about it now. It’s not that nobody knew that this was going to happen. History has this habit of repeating itself because we’re all stupid.
If you write CSS and ‘need’ to use prefixed properties then you need to include all the
relevant ones for Gecko (-moz-), Microsoft (-ms-) and if you need to serve smartphones also include
Opera (-o-). And if and only if the property is well supported also include the a version without a
prefix, the so-called WC3 version. Using only -webkit- prefixes is nuts and makes you look
like an ass. So stop doing that! Comparing a prefixed webkit web to IE6 is a little disingenuous and
tantamount to political rhetoric.
IE6 lacked not only features and useful properties but was intensely buggy. This is not the case with prefixes.
I could do with less
I’m glad that I’ve adopted using pre-processors to cope with the tedious complexities of prefixes. By creating a mixin for box-sizing with all the prefixed variants I can easily reuse this single mixin throughout the project. This is so useful that this is the main reason why I’ve opted for LESS with its clean implementation.
What if a new browser vendor came along and wanted to add all these fancy new features? The only real choice would be to either support the -webkit- prefix or to avoid the whole prefix mess altogether. The latter seems like the only way out. Prefixes, in hindsight, should not have been let loose on the open web. PPK called it.
Solution: Just ignore it
So what are browser vendors to do? Well, what they could consider is to ignore prefixes, including their own, and render a specific property the way they render any other property. That, in effect would give them access to -webkit- and other prefixed properties without the bat shit crazy move of actually explicitly supporting them. So, for example, Mozilla would be able to parse -webkit-border-radius because they already support border-radius but could also hold off on parsing -webkit-text-size-adjust until they have the feature well replicated. In effect, as soon as they feel they can implement a property without a prefix they could ignore all prefixes. The current practice is to add the ‘W3C’ version at the bottom and it’s always the last repeated property that gets rendered. It’s not perfect but it’s a whole lot better than ceding -webkit- as the de-facto standard.