On Monday at the CSS Working Group, Microsoft, Mozilla and Opera
announced that each are considering supporting some
I include here Bruce Lawson’s excellent summary:
Lots of developers, despite evidence to the contrary, have assumed that mobile Web = WebKit browsers, because that’s the rendering engine in Android and iThings. Suppose the site was made a while ago and used the experimental, pre-standardised code
-webkit-border-radiusand didn’t use the cross-browser future-proof method. The real CSS property
border-radiushas been long been standardised and supported without prefixes in all the major browsers. But the
-webkit-prefixed version still lingers on in Safari and Chrome, so that legacy code looks fine in the webkit browsers, but broken in Opera, Firefox and Internet Explorer.
We’ve been through this fight before. A few years back, Internet
Explorer proposed the
X-UA-Compatible header, which would mean that IE8 would act like IE7 unless you specifically told it to act like IE8. The proposed solutions back then were similar to what we’re
seeing today in response to
-webkit-* CSS in non-WebKit browsers:
developers shouldn’t be lazy; developers should do it right; sites
should break if they use WebKit-only CSS in order to punish the
developer; use this library to help you do it right (LESS for CSS
pre-processing on the server side, prefixfree on the client-side);
WebKit should stop supporting a prefixed CSS property once it supports
the unprefixed version; vendor prefixes are a broken concept and should
None of these approaches will work.
Expecting developers to just Do It Right To Begin With™ is a noble goal, but it doesn’t work like that. Everyone has deadline pressures; most people are not on the bleeding edge of the web standards community; the tension between “make it work today” and “make it right for the future” is never going to go away, no matter that we wish it would. The way to success is to align the right way to do it with the easiest way to do it; the way to success is to make correctness the path of least resistance. This is what informs the HTML5 “pave the cowpaths” approach, and it’s that way for a reason; if correctness requires extra work, then at least some people will be incorrect through lack of time or lack of knowledge.
Breaking websites, by having WebKit deliberately stop supporting a
-webkit property once it supports the unprefixed property, is not
going to happen. The WebKit team have explicitly stated that they won’t
do that, for “backwards compatibility reasons”. Also, frankly, expecting
them to is naive; they should make websites break just in order to teach
developers the Right Way To Do Things, when those websites currently
work? Remember, it’s not developers who are punished by this; it’s the
users of the sites, because those users get a new phone or a phone OS
upgrade and suddenly half the sites they use don’t work. This hurts
them, and they’re who we’re doing this for. The WebKit team are looking
out for WebKit, but they can’t be blamed for that; stuff works for them,
There’s an argument that users who find their sites broken will blame the sites, and then the site developers will fix the problem. I disagree. If I decide to try Opera Mobile or Firefox on my phone and half the sites I use don’t work, I’ll say: oh well, can’t move to that, then, and I’ll go back to the built-in browser. This is the Microsoft argument: one broken program will prevent an upgrade, and they’re right. What we get is de-facto lock-in, just the same as all those businesses which couldn’t migrate away from IE6 because of their intranet.
Using a server-side preprocessor or a client-side JS patch to turn
-webkit-some-property, -moz-some-property, -o-some-property, -ms-some-property
is a useful tool for developers who know what they’re doing but can’t
be bothered to type it all in. Think about it: if I just use the
unprefixed standardised property right now, then eventually (when the
browsers all implement it) my site will work! I don’t have to do
anything to make that happen; I’m out in front and waiting for
technology to catch up with me. It does not help the developers who
are actually affected here, the ones building sites with only
CSS properties in them, the sites that Bruce calls “legacy code” above.
And it’s those legacy sites which are compelling Mozilla and Microsoft
and Opera to debate supporting that WebKit-only CSS.
So, then, smart-arse, what’s the solution, if it’s none of those?
Well, obviously, the evangelism efforts should continue. Progress is made. People do learn. It’s slow, but we get there in the end. What we’re talking about is an interim solution in addition to that.
I think @leaverou‘s prefixfree JS library has the right idea,
it’s just backwards. Prefixfree takes proper CSS (an unprefixed
property) and turns it into all the vendor-specific prefixed properties,
so that you write CSS-of-the-future and the library turns it into
CSS-of-today. It’s a polyfill. What’s wanted here, I think, is something
like prefixfree but which takes CSS-of-the-past (
and turns it into CSS-of-today
-webkit-some-property, -moz-some-property, -o-some-property, -ms-some-property, some-property).
This wouldn’t be a hard polyfill to build (it’s just prefixfree,
tweaked), but then of course you have the problem that no-one knows
about it. So here’s the second part of the proposal: common JS libraries
should do this sort of thing by default. Imagine if jQuery fixed this
stuff for you. I think, without wishing to sound snobbish, that most
reasonably-complex websites include some JS (progressively enhanced,
ideally), and most of those use a library. The developers we’re talking
about (and this is the snobbish part), the people writing legacy
WebKit-only code, will have that WebKit-only code automatically patched
to work with all other browsers without having to know that it’s even
happening. The ones who are short of time get that time back; the ones
short of knowledge can learn on their own time and are helped to not
screw their users in the meantime.
This sort of view is problematic. I’m proposing giving a man a fish, not teaching a man to fish, and that’s wrong. I agree. In this instance, given the choice between not educating a developer or not screwing some of his users, I’m choosing the users. I don’t know a way to choose both. It’s also problematic because I’m suggesting that library developers do all the work, and everyone using that library takes a performance hit even if they don’t need to. So, I’m sure there will be other suggestions, and I’d love to hear them. I’d just like to stop hearing all the ones above that don’t help the problem get fixed.