Thursday 9 February 2012
Alternatives To Supporting -webkit Prefixes In Other Engines
Since news spread that the non-Webkit browser vendors are moving towards supporting some -webkit-prefixed properties, lots of people are pushing back with alternative suggestions, for example Daniel Glazman. Many of these are good suggestions, but here's why they won't work for the properties like transitions, animations, and transforms already in wide use:
- Evangelize Web developers to not use prefixed properties on production sites. This is swimming upstream against trends in Web development and market forces. At every Web dev conference I've been to, on almost every Web dev site (including browser vendor's own sites), Web developers are encouraged to use vendor-prefixed properties. Web developers who refrain will lose business to Web developers who don't. Ergo, not going to happen.
- Evangelize Web developers to use prefixed properties with "all browsers' prefixes" (sometimes automatically through preprocessing tools or even CSS extensions). This would help in some ways, but despite us browser vendors and a large chunk of the Web dev community pushing this approach for a long time, even with tool support, Web devs don't do it consistently enough. Even when we specifically contact big, clueful sites we have a good relationship with (like Google) to get this fixed, we often don't succeed. So I don't think one more passionate (angry?) round of evangelism is going to make the difference. Of course evangelism can't help with sites that are no longer actively developed.
This approach has a big downside, too: it can severely limit the usefulness of prefixes in the first place. As soon as one browser implements a feature with given syntax, Web content can start assuming all other browsers use the same syntax and semantics, which forces those browsers to behave exactly as if the feature had been deployed unprefixed in the first place --- especially when Web developers include the unprefixed syntax as a "fallback" in case prefixed support is removed. Even if we could succeed at the evangelism, with this approach we might as well have not used prefixes in the first place.
- Teach Web developers not to rely on vendor prefixes by dropping support for them once standard versions exist. Webkit people have already said they won't do this. Furthermore, it encourages Web developers to go the "all prefixes plus standard name" route for everything they do, which makes prefixes pointless, as explained above. Doesn't help with deployed content anyway.
- Ignore the problem and hope that it goes away without us having to do anything distasteful. Um.
Some of the suggestions for things we could do in the future are good, like disabling experimental features in browser releases, but they won't help us out of the current situation. Maybe I'll discuss them in another post.
Note that trying alternatives that end up failing will have a huge cost to the open Web: it will delay the onset of a multi-vendor mobile Web, which is critically needed for the open Web to survive. I hate having to support -webkit prefixes, but "desperate evangelism while the problem gets worse, followed by supporting -webkit prefixes" would be even worse.
Meanwhile, to the people who think the solution is for Mozilla and others to just "work harder" at evangelism, or implementation, or standards work --- I cast aspersions in your direction. You have no idea how hard we work. I personally have never worked harder in my life, and I know that's true for many other Mozilla people. We hire more people, but the workload increases even faster. Meanwhile, Apple won't even hire a single full-time standards editor to help their proposed CSS properties reach standardization, which is a large part of what got us into this mess in the first place.
Comments