On vendor prefixes in CSS and vendors implementing them

On Monday at the CSS Working Group, Microsoft, Mozilla and Opera announced that each are considering supporting some -webkit- prefixed CSS properties.

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-radius and didn’t use the cross-browser future-proof method. The real CSS property border-radius has 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 be abandoned.

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, after all.

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 some-property into -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 -webkit 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 (-webkit-some-property 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.

More in the discussion (powered by webmentions)

  • (no mentions, yet.)