There's been a lot of discussion about vendor prefixes. I think the community is a bit torn over them. They were fun when one browser was actively implementing them but then more started to do it and it just became a hassle. At least, that's the general vibe I'm getting. There's also the camp that still thinks vendor prefixes work. Features should not get implemented until they are standardized to prevent the quirks mode residual from the 1995 browser war. Just to be clear, I'm in the "they do work" camp.
tldr: moz and ms are on the edge of implementing other vendor's prefixes. This _will_ kill the concept of prefixes. I wrote a bit about the how's and why's, pretty much concluding that it's their own damn fault. In the end I give two proposals of at least preventing this problem in the future, without killing prefixes. I also offer some suggestions in evangelicalism and tooling of the existing mess.
Meh
I generally don't really write or speak about css. I'm a js kinda guy that also knows about a fair bit about css and html, but I'm not as specialized in those areas as I am with js. I generally don't really care about hardcore discussions about the semantics of html or the syntax of css. I have some opinions about them, but none I feel generally compelled to express.
However, the minutes of the recent
CSSWG meeting (good read!) revealed that Mozilla and Microsoft (and Opera?) are actually beyond contemplating the support for css vendor prefixes that are not "theirs". This is mainly a story about the domination of webkit, especially (but not solely) in the mobile world. They feel like they are pushed in a corner because developers have grown accustomed to the
-webkit- vendor prefix and don't really bother with other prefixes anymore. This causes other browsers to be left with the fallback content, if any, which of course doesn't sit well with those vendors.
Blame
Now there's an interesting point to this. They feel like they were pushed in a corner. In reality, I think it's their "slow development" (yes, even though browser updates have increased a lot the past few years) that's now put them in this position. Let me put it more directly; They caused this themselves. And they see only one way out; kill that which was introduced to prevent another browser war. Holy crap!
I'd like to quote a quote from
the minutes that painfully tried to squash this important point:
Florian: Regardless of how we ended up here, if we don't support webkit prefixes, we are locking ourselves out of parts of the mobile web.
. Wait wut? So it _doesn't_ matter how we got here? The hell it doesn't!
Of course I can see their point of view. They didn't put these experimental features as a priority but the community loved them and implemented them anyways. And because other browsers didn't implement them, the feature was not standardized (because amongst others, features need to have a few implementations before they can get standardized) and so webkit couldn't drop the prefix. And they didn't. This was proper behavior on their part. But the lack of other implementations and the duration of the prefix caused developers to grow accustomed with the webkit prefix. They showed it to their dev friends, they showed it to their friends, they showed it to their boss and of course they showed it to their designer. The designer wanted it in and *BAM*, we've got prefixes in production. Would this have happened with a live span of three to six months for a prefix? I don't think I have the authority to factually answer that question.
QQ
So webkit didn't (couldn't) drop the prefixes but developers were getting forced to implement them anyways. So we have prefixes in production. This is a problem. But the problem did not get solved. The feature did not get standardized even though more and more people were starting to use it and to rely on it. The other browsers for whatever reason did not implement the feature and it was starting to harm them. They were being served backup content on production sites that wanted to use bleeding edge technology in the website that has become their business card in every day life.
So now these vendors, after finally implementing the feature (in most cases I think their implementation just followed the implementation that had existed for over a year and was pretty stable for at least that vendor), suddenly discover that devs have learned to just use the
-webkit- prefix and don't bother with a unprefixed version, let alone the prefix for another browser. In fact, it seems that they are kind of demanding or expecting devs to use their prefix immediately. Which of course does not work for two reasons; Devs don't regularly update code that's older than a month (or even less) and many devs don't actively keep up with which features were actually implemented in other browsers. I mean, I think I do a fair job of keeping up and I can't tell you right now whether Firefox now supports all the animations or maybe just a subset of it. Let alone Opera or IE.
iekit6
In the minutes, there was also this nice quote.
Tab: IE6 monoculture of desktop. WebKit monoculture of mobile. It's the same problem. He's right and he's not. He's right that webkit is now the IE6 of mobile. It will be interesting to see how we look towards webkit in two or three years, when updating mobile browsers has become a normal thing and a new vendor has risen to the mobile top. But for now, yes, webkit rules the mobile world. I'm sorry for Opera, but I think that once the smart-phone culture hits the poor countries, their reign will be over fast. The reason is simple; the poor countries where Opera has such a big market share will start with older versions of smart-phones (because they are cheaper, of course). They _will_ come with native webkit browsers. Users will switch because they're not tied to the Opera brand. They just want to surf the web. So the reason I don't agree with the second part of Tab's remark is that I think we'll be stuck with webkit even longer than we were (are?) with IE6 simply because there's hardly any update model on mobile. Certainly not the older devices; vendors won't care!
A bridge too far
Alright. So we have a problem. Webkit's reign seems to surge and is causing devs to use "beta" prefixes in production. We've crossed that bridge and the way back is long (I'm not convinced we'll ever "find our way back" due to politics). Devs wanted/needed to use cool features and for a long time the only available option was the -webkit- prefixed feature. So that kind of became a "de facto standard". Some (I still hope "most") devs did know what the -webkit- prefix was for, but there seemed no point in adding all the other vendors prefixes. (As a side note, I think this is actually the correct behavior as these prefixes were meant to be able to experiment with different syntaxes. If devs would blindly use the same syntax for all the different prefixes, the goal of the prefixes is lost and we might as well drop them now. To be honest, I think I've only seen this system work a bit for gradients, because vendors were working on that almost at the same time, giving them a chance to actually influence and experiment with the syntax. It feels like vendors missed that opportunity on the webkit specific features currently under discussion, like animations and transforms.) The core reason we have this problem seems to me to be the lifespan of the prefix.
I feel strongly that if a feature was prefixed for no longer than three to six months, the problem of global implementation would be overcome. The prefix would be dropped and would not risk the chance of being adopted in mainstream and production sites. To this end I'd like to put two proposals up for discussion.
Ways out
The first is one that was literally mentioned in those minutes. plinss: Should discuss putting experimental properties only in experimental builds
YES! Why did the workgroup not even respond to this? You might limit the amount of experimenting to devs amongst each other, but is that really a bad problem? Most devs I know (ok, biased circle..) have at least one or two experimental browser versions installed. And when somebody tweets "AN AWESOME DEMO, NEED XXX NIGHTLY FOR THIS!" I'm likely tempted to get that nightly, or at least look at the screenshot/screencast/whatever to check it out. If it's awesome enough, word will get out. So bound (new) prefixes only to your nightly. This will definately prevent them from being used in production. This might mean you'd have to release a beta version for mobiles for as far as that's possible. I'm not saying this is ideal :) But keep in mind that the current system isn't working out for ya either!
The second solution the csswg might want to consider is to allow a standardization request from vendors that have implemented some feature, if no other vendors have implemented it in the past six months (/arbitrary time). If the featue is awesome enough, other vendors will jump on it. If they don't they probably don't think it's important enough. This idea doesn't really change much from the real world. Webkit's implementation for animations and transformations has pretty much ended up being the de facto standard, for lack of other implementations for a long time.
Note that this does not undermine the purpose of the prefix. It still prevents a browser war of implementing the same feature and ending up with different behaviors. But when a feature is neglected for such a long time, one can hardly speak of war. At least not in terms of implementation. In my opinion it's fine for offering a rich suit of features. It also has a side effect of css becoming a slightly more fluid standard, but that doesn't seem to have hurt the html5^H specification. So is that really a problem? Bring on the CSS4^H!
Tooling and evangelicalism
Of course it doesn't end there! People have to be thought! We've also got "css waste" to be cleaned up. Let owners/developers of production sites that use prefixes be noted that they are using prefixes. Opera actively tries to approach these websites, but that's not enough. We need more momentum, we need more leaflets, more flyers, more talks, more awareness, more education, moar, MOAR!
For instance, I'm thinking of a js script that would go through all the style sheets on your website, find prefixes and replace them with the (proper!) syntax of the prefix of other browsers. You might think this won't work because that syntax might change, but it could if it would be served from a CDN. Especially with the lazy loading culture we've evolved into, this dependency should not be a huge problem anymore. The script on the CDN can be esaily updated with the current version when a browser changes syntax or drops some feature and you wouldn't have to worry about prefixes anymore. Yes, this comes at the cost of requiring JS for this to work, but I'm open to alternatives.
Another key role of tooling are generator tools. I see many of these (I post them regularly on JSGoodies) and they allow you to visually play with a certain style and they will output the required css in various browser flavors. The key point here is not that these tools should be developed and hosted by people like me, but by the standardization committee, in conjunction with browser vendors. Set up a special branch that develops these tools. Make them available from the website of standard bodies. Let vendors work together and notify this group of relevent updates, they will want this as it also helps compatibility with their own browsers.
Closing arguments
I think it's very hard to convince web developers not to use an awesome feature when you release it. At the same time the vendor landscape has changed and you can't just ninja in a specification for a new feature. But when this process takes too long, the developers will ignore the fact that a feature is beta and use it anyways. I see two ways out of this conundrum. Either we strongly limit the life span or availability of the prefix by making them only available in beta versions of a browser. Or we force other vendors to pick up on the slack by giving them a certain time to come up with their own implementation of a certain feature, or forfeit that possibility after a certain amount of time by allowing the first vendor(s) to submit a standardization request without the need for multiple implementations. Of course this standardization process still needs to be fast, regardless.
I think that the latter is more appealing to vendors because it means they can still use their new cool ideas in their production browser and actually have a chance of deciding how to implement a certain feature. That would then only depend on the promptness of the other vendors and the coolness of a feature. The ball is in your court, vendors. Don't kill prefixes, work with them!
Disclaimer: I am not affiliated with any browser vendor, nor do I have a problem with any of the vendors mentioned. I'm just expressing my concerns and am hoping to provide the explanation and possible solutions to the problem at hand.
Ok. Back to js1k and bikeshed for me ;)