Remember the days when designers and developers only cared about how their site looked in IE6, and couldn’t or wouldn’t care about the rendering in the Mozilla or Opera browsers? Those days are returning quickly as mobile sites “enhance” their experience for WebKit browsers. You’d think that we would have learned from the last time around.
It starts with a seemingly sensible decision: you have a website for which you wish to improve the experience for users of smartphones and tablets; clearly, the most-used operating system for smartphones and tablets is iOS and Android, and therefore it makes perfect sense to optimise the site’s appearance in WebKit, the rendering engine upon which Safari, Chrome, and the Android and Nokia browsers are based.
A few -webkit-border-radius here and a couple of -webkit-text-size-adjust there, and you’ve got yourself a pretty little page and the world’s a better place for it.
Well, not exactly.
It turns out that such is the dominance of WebKit browsers in the mobile space that Mozilla is considering adding support for -webkit- CSS properties in its mobile releases.
As the minutes from the W3C CSS working group meeting from last Monday show, non-WebKit browser vendors are finding that their browsers are being served up fallback content, with the preferred mark-up being shown only to WebKit browsers.
Mozilla, Microsoft, and Opera claim that the time has arrived when they can no longer fail to support zero -webkit- properties, but a world where vendor prefixes are no longer restricted to one vendor is a world that I want to avoid.
Opera says that it is losing market share by not supporting -webkit- properties, and Mozilla may resort to user-agent spoofing to provide the optimal mark-up for its users.
This is not how the openness of the web is meant to work.
Of the possible alternatives, I think that Mozilla implementing -webkit- properties is the worst of the lot. It would legitimise the usage of properties that are meant to be experimental, mutable, vendor-specific, and liable to disappear at any moment. Even if the implementation is only on a selected number of properties and restricted to mobile Firefox, it cedes CSS field to WebKit, and could be the start of a counter-productive cycle of developers and designers thinking that using a -webkit- property enough times will force Firefox to support it. It would leave Mozilla effectively beholden to whatever direction Apple and Google decide to take WebKit in. I don’t see how this is any better than being bug compatible with IE6.
A better approach would be to rapidly standardise the properties that Mozilla, Opera, and Microsoft feel are necessary, and thus avoid the need for the -webkit- prefix for mobile content. But we are talking about a W3C working group here, and it is notorious for matching it with glaciers in the speed stakes when it comes to finalising standards. Hopefully, the spectre of having -webkit- cemented into the web would shock them into action.
An idea proposed during the CSS working group meeting, which appealed to me in theory, is to have the vendor prefixes dropped after a period of time, and to have prefix support restricted to non-release builds. In practice, though, it would mean a return to the bad old IE6 days where browser innovation stagnated, and the browser vendors would not let that happen again.
Another alternative, proposed by Daniel Glazman, co-chair of the W3C CSS working group and “glazou” in the meeting minutes, says that developers should add in the other vendor prefixes for any features where -webkit- is used. This could potentially mean up to half a dozen individual vendor declarations for a single item, such as a background gradient–something that I would not like to code by hand.
For that reason, I would be looking to a CSS tool with a feature like Stylus’ interpolation in order to reduce the tediousness of repeating the similar declarations over and over again.
Short of having the CSS standard rapidly updated to reflect the modern mobile web, Glazman’s final proposal is the least-offensive option left on the table.
If you are still creating CSS without the use of a pre-processor, now would be the time to switch over to one.
However distasteful and extraneous it may appear to maintain multiple vendor declarations, it is a far better alternative than spending the next decade maintaining -webkit- declarations that function differently in IE than in Safari.