I'm writing a CSS book

JavaScript archives Compatibility CSS coaching Thidrekssaga QuirksBlog Donations Politics Mobile About COH

sitemapcontact

The vendor prefix mess

This is one of those weeks where everything happens simultaneously. I think that the vendor prefix discussion is the most important topic, so that’s what will get my attention.

Daniel Glazman, co-chair of the CSS WG, posted a call for action that warned of the dire consequences of web developers using only -webkit-prefixed CSS declarations: IE, Mozilla and Opera would also implement -webkit-.

I will argue that the proposed solution of making web developers aware of the problem may be technically and ideologically correct, but does not address the true causes of the problem: the developer-hostility of vendor prefixes, and the lack of mobile test devices.

The proposed solution puts the burden of solving this problem on web developers — in addition to the vendor prefix system maintenance and worries about device labs.

A secondary problem is that “WebKit” (which is neither a browser nor a browser vendor) is made into a bogeyman that threatens to take over the world. This is, to put it mildly, bullshit. It is not helpful at all for solving our current problem. Besides, this sudden demonization makes Google representatives, especially, a bit defensive and thus harder to talk to.

In fact, I’m ashamed of the reaction of my peers here. It seems web developers are lazy and stupid and don’t know what they’re doing, while “WebKit” (meaning Google) is an evil empire — just as back in the glorious past with Microsoft and WaSP and all the rest.

Instead of making simplistic comparisons to past heroic ages we should ditch the current vendor prefix system and get web developers to test in Opera Mini on their phone. That, as far as I can see, is the minimal change required to get the situation under control again.

Finally, we have to accept that part of the blame lies with ourselves, because we talk too much about the iPhone and not enough about other phones.

The problems and their causes

Let’s split the argument into its component parts. I find that I agree with some, and disagree with others:

• Some web developers use only -webkit- prefixes, disregarding the other browsers. I don’t care about the prefixes, but the underlying problem of not testing on mobile except on the iPhone or Android is a bad thing and should stop. Still, there are significant extenuating factors that aren’t being addressed.
• WebKit is the new IE6, where “WebKit” now means the iPhone. I agree. In fact, I called out this problem two years ago. Gloat moment. I. Told. You. So.
• IE, Mozilla, and Opera will implement -webkit- prefixes. Let them. This is the single part of the argument that’s also part of the solution.
• Removing vendor prefixes will break the standardisation process. Nonsense. There are alternatives; notably a -beta- prefix that will be used by all browsers.
• The WebKit juggernauth is threatening to wipe out exotic browsers such as IE and Firefox. Poppycock! There is no WebKit on Mobile, neither technically nor politically.

To get a real view of the problem we have to identify the root causes instead of studying the symptoms.

The current prefix situation is caused by two initially unrelated problems coming together in a big way:

1. Web developers don’t want to bear the brunt of the vendor prefix system any more.
2. Web developers want to go mobile, but do not have enough devices for really proper testing. So they go iPhone-only.

Vendor prefixes are flawed

Two years ago, I ranted a bit against vendor prefixes. Although I was wrong in that the problem they solve does really exist, I was right in that vendor prefixes are a disaster for developers. Some developers just don’t get it, others honestly forget to add all prefixes, still others don’t care.

What’s important to note here is that the problem is with the prefixes, and not with web developers. If standards make web developers’ lives much harder, web developers ignore standards. This was true back in 1998, it’s still true today.

Vendor prefixes are the most developer-hostile solution imaginable. The vendor prefix idea was flawed from the start by putting the full brunt of namespace management on web developers.

Therefore I do not believe that the current campaign to implore everybody to do the right thing and bloat their CSS is the correct answer to the problem.

To me, the solution seems obvious:

1. Abolish the current system.
2. Let IE, Firefox and Opera implement -webkit-.
3. In the future, denote experimental features with a generic prefix such as -beta-. This warns everybody that the feature is not yet permanent, can be used by all browsers, and is much better for developers. Besides, if -beta-coolfeature gives different results in different browsers, this serves as a powerful reminder to web developers that they’re meddling with forces they can only comprehend after a study of the spec.

Update: I discuss the -beta- option further in a new entry.

Opera, in particular, has a history of making such moves. It spent most of the noughties copying IE bugs to make its browser more suited to the websites that were out there. It went a bit too far for my taste, but the underlying principle is correct and applies to the vendor prefix situation.

I welcome the opportunity to get rid of the current system, and feel that there are enough alternatives available to create a “beta namespace” — alternatives that will shift the onus of maintaining the system from web developers to browser vendors and standard committees, where it belongs.

Let’s turn to the other components of the problem.

Mobile test devices are scarce

As far as I’m concerned the entire situation hinges on getting web developers access to more mobile browsers. Where you can download any desktop browser to any desktop computer with a minimum of fuss (IE to Mac is hardest, but even that doesn’t take outrageously long), the situation is quite different on mobile.

Consider a web developer who’s heard a lot about the mobile web in the past year. His boss agrees that the iPhone is important, because his clients think so, but he doesn’t want to pay up for five or six test devices. What is this web developer to do?

Well, he naturally owns an iPhone, and decides to test his sites on it from now on. That’s an excellent decision: even though iPhone testing cannot substitute for true mobile testing it’s a necessary first step.

Up until now our web developer has made but a single mistake: he hasn’t installed Opera Mini and added it to his test programme. That can be easily forgiven in a newbie, because all well-known web developers are mostly talking about Safari on iPhone (with a bit of Android on the side).

Now what really ought to happen is that our web developer gets access to an Android (better yet: two or three), a BlackBerry, a Windows Phone, a Symbian device, and maybe a Samsung bada or an S40. Even though all these devices but the Windows Phone have a WebKit-based default browser, our web developer would be exposed to the true multi-faceted nature of the mobile web.

Unfortunately this won’t happen soon. Bosses won’t cough up enough money yet, and of all the myriad device vendors, only BlackBerry (and to a lesser extent Nokia) see that they have to give away lots and lots of devices to web developers in order to become a Browser To Be Tested In. The others have not yet seen the light.

Apple does not need to give away test devices due to its popularity, but the other mobile browser vendors do. It’s share the loot or be excluded.

Opera has it easy here. It has a browser for every platform but Windows Phone, and should be pressing its advantage to the hilt by getting web developers to install it.

Anyway, although the root problem isn’t going away any time soon, installing and testing in Opera Mini is a sufficient proxy in the short term. That’s why those who are concerned about WebKit dominance should encourage web developers to test in Opera instead of giving unrealistic instructions about vendor prefixes.

Except, of course, that there is no WebKit dominance.

There is no WebKit

There is no WebKit browser. Anyone who thinks otherwise just hasn’t been paying attention and may not participate in this discussion.

There are, to my latest count, Safari desktop, Safari iOS, Chrome desktop, Chrome Android, Android WebKit (in various flavours), BlackBerry WebKit, Nokia WebKit (in various flavours), Samsung Dolfin, LG WebKit, Palm Webkit, NetFront WebKit, Obigo WebKit, and UC WebKit. Thirteen browsers, eleven vendors — or fourteen, if you count the Android vendors separately.

Why anyone in his right mind would think that Apple, Google, RIM, Nokia, Samsung, HTC, Sony Ericsson, Motorola, LG, Palm, Access, Obigo, and UC have all entered in a sinister conspiracy to end browser diversity forever and always is beyond me. Or maybe it’s the enigmatic puppeteer “WebKit” that is bound for world dominance?

Cut the crap about WebKit and threats to diversity and stuff. This is not helpful at all.

Worse, it gets people who work on the technical project called WebKit, as well as representatives of WebKit-using browser vendors, especially Google, distrustful. They don’t bear any blame for the situation whatsoever: they have faithfully implemented the vendor prefix system and improved their browsers with beta CSS features, just like all other vendors did.

The reason they’re being called out now is that they were earlier with implementing many features than the other browsers, which led web developers to look specifically to them. Being better than your competitor is a fair move in the browser war game we’re playing, and should not be a reason for censure.

So despite being blameless they’re still being made to look like bogeyman, they resent that, and meaningful communication breaks down. Not helpful. Harmful, in fact.

The silly black-and-white image of WebKit vs. the good guys, unthinkingly copied from the late-nineties Age of Heroes, must go. It’s simplistic bullshit.

(That said, this particular flavour of simplistic bullshit is pretty prevalent in US mobile blogging circles, too. There it’s Google being cast in the role of the Microsoft of the late nineties vs. the ever-shining Apple knight. So it’s clear where web dev bloggers got the idea, and why it’s especially Google that acts defensively.)

I am ashamed of my peers here, and would like to extend apologies to Google on their behalf. Once they come to their senses they’ll agree with me.

Conclusion

Concluding, the solution to the vendor prefix problem is not to tell web developers to change existing sites, but the following:

1. Ditch the current vendor prefix system.
2. Instate a new one that uses the same prefix for all browsers.
3. Get web developers to install Opera Mini on their iPhones and test their sites.
4. Don’t blame Google or “WebKit.” They aren’t responsible for the situation.
5. In the long run, convince device vendors they have to give out a lot of devices to web developers.