The -webkit- prefix will ruin the mobile web

WebKit is fast becoming the IE6 of the mobile web as developers happily target it with non-standardised CSS.

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.


Some would say that it is a long way from software engineering to journalism, others would correctly argue that it is a mere 10 metres according to the floor plan.During his first five years with CBS Interactive, Chris started his journalistic advent...


This is a very well stated, but entirely false analogy, Chris. IE6 (along with 7, 8, and 9) represents the failure of Microsoft in software development. The -webkit prefix is disruptive because it is used by the innovators/industry leaders in design and development for the mobile web. This is a challenging problem to solve, but I don't think a misleading comparison like the one you've made here isn't going to help matters along. And if W3C tackles this in a governmental manner I fear it will do about as much for developers as many government solutions do for social issues: one set of problems will simply be replaced with another (albeit newer and shinier ones :)


What would be so hard for a Webkit or Mozilla browser to see "border-radius" and do what it needs to do without the prefix.


That's why I'm using LESSCSS to encapsulate all the vendor properties into one call -- keep things tidy and give the flexibility to add/remove prefixes quickly in the future.


IE6 was the best browser at one point, and it had lots of extensions for a wide variety of CSS/HTML effects. The real problem came because developers used these extensions and wrote webpages for IE6, ignoring the standard. Now we are back at the same place. Developers are all excited about using -webkit extensions to CSS and using them to the detriment of non-webkit browsers. Developers need to follow the standards and not use the -webkit prefix (because it IS NOT part of the standard). Code to the standard and make the site functional in the standard. If you want extra fluff add it afterwards and make sure it degrades gracefully for a couple versions back of each browser that hits your site.


does the -webkit prefix break anything for other browsers? I'm normally a strong advocate for adhering to standards. However, if there are no negative consequences for users, what's the problem? What's more important : user experience or a tick from the W3C CSS validator.

Editor's Picks