the trap of vendor prefixes
This week a conversation surfaced that I consider to be one of the most interesting, front-end related pieces I've read in a long time. Several browser reps came together on a csswg list to discuss the implementation of vendor prefixes. The conversation is surprisingly direct and to the point, shedding some light on the internal workings of how the people behind the specs go about their business. That and the actual content of the meeting were enough to spawn a fleshed-out reaction.
microsoft and mozilla
The meeting spanned several different issues, but the most interesting part is where they start talking about vendor prefixes, more in particular the demand of Microsoft and Mozilla to implement support for a selection of -webkit prefixes into their own rendering engines. While this might sound like a crazy suggestion at first, there's actually some pretty solid ground for such demands.
I found on the rough analysis of top 1000 websites, several percent use webkit prefixes without a fallback for others. 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.
So there we are. Due to its current reign on mobile devices, some authors haven't bothered to support anything else but webkit, breaking support for current IE, Opera and Mozilla mobile initiatives (and all future non-webkit browser to come). Even when similar (or equal) functionalities are available in the non-webkit browsers, these sites will still provide sub-par experiences or even fail to work altogether. A serious problem for Mozilla and Microsoft who are trying to break into the mobile market. For them, simply mapping -webkit properties to their own (or by then standardized) properties sounds logical enough.
Of course this would be setting a horrible example, putting the gates wide open for others to do the same and making the whole vendor-specific properties discussion even messier than it already is. Chances are slim that Microsoft and Mozilla will be allowed to pursue their plan, though you might wonder who'll stop them if they're really losing out on market share this way.
A rather tricky problem that will no doubt spawn many more discussions, but there is more.
... and then it hit me
There's enough legacy content that there are some properties that we can't drop the prefixes.
Oh my.
You know how everyone these days is quite unanimous in claiming ie6 is a shit browser? A good 5 or 6 years of evangelism lead to the notion that ie6 is simply evil, a morbid plan to break evolution and cripple the web. Of course it's a natural (human) phenomenon, if you want to reach a large audience you need to simplify your message. It led to the slow but sure demise of ie6, but now we're finally being confronted with the backlash of this anti-ie6 war.
People who actually remember the release of ie6 might realize that ie6 was not a bad browser at all. Compared to modern browsers it's a heap of junk, but in its day ie6 was quite the flashy browser. What made ie6 bad was our own industry. We developed web sites that worked only on ie6 and failed (horribly) on other browsers, actively stifling innovation as people (companies) were not willing to upgrade. We made it that ie6 is still alive and we should carry the weight of that responsibility. But rather than face this reality, we just told people ie6 sucked and cleaned ourselves from any guilt.
Web standards activists are teaching people to use -webkit-. People like Lea Verou. Their demos are filled with -webkit-. You will see presentations from all the web standards advocates advocating people to use -webkit- prefixes.
And so, 10 years later we find ourselves in a similar situation. Webkit rules the mobile market, so people who develop for mobile use vendor-specific properties and completely ignore emerging standards (sounds familiar by now?). Sites look bad or break in other browsers, but since that's just a minority (or simply a problem invisible for now) they don't care one single bit. Mobile development is bleeding edge, so no time for best practices, right?
Demos are spread with webkit-only properties, evangelists are eagerly and willingly falling in the same traps, having learned little to nothing from past mistakes. Sure we can hide behind the fact that people should not just mindlessly copy demos from the web, but that's just another way of failing to face reality. Our industry, safe all our efforts to change things, still consists mostly of "code-grabbers", who pick demos from the web and go to Experts Exchange if things don't seem to work like they assumed they would. If we feed them the wrong information, we are the ones to blame.
conclusion
Maybe vendor prefixes shouldn't have been allowed in production versions of browsers, maybe vendor prefixes themselves were a dumb idea to begin with, but it's pointless to blame anyone else but ourselves, the web development community. We are the ones creating a situation where browsers can't evolve because they might break the current web if they do. We are the ones writing browser-specific code, effectively halting the future of the web.
What can be done? Very little, except educate wisely and make sure that you build sites with progressive enhancement in mind. Make sure your site works well on basic browsers, innovate for more modern browsers and safely predict future implementations and standards as to make sure others will profit when the time is there. If webkit turns out to be the new ie6, we have only ourselves to thank for it.