Web developers are playing favorites, making websites exclusively for iPhone or Safari or Chrome. Now, other browsers want to fight back by pretending to be those browsers. This is not good.

The Webkit Drama

If you didn’t hear the news that’s been swarming around the Internet earlier this month, here is what’s going on: Non-Webkit browsers (Firefox, Opera, and Internet Explorer) want to support the -webkit- CSS prefix. If those browsers masquerade as Webkit by adopting this vendor-specific prefix, -webkit- could become a de facto standard, making it harder to differentiate experimental features between browsers. More importantly, this could cause a ripple effect affecting the future of the Web.

What’s the Big Deal?

The evolution of the Web depends on three groups: web browsers, web developers, and standards bodies. It wasn’t until the adoption of HTML5 that these groups started to work in harmony: Standards bodies create the standards with input from the community, browsers follow the standards, and developers make standards-compliant websites. In the pre-HTML5 era, the Web was slow to evolve due to conflicting interests and an imbalance of power between these groups.

So how does this -webkit- controversy play into this? Lazy developers decide to play favorites and choose browser-specific features. Browsers retaliate by ignoring standards and adapting to developer laziness. This behavior gets written into the standards, reversing the flow of the standardization process. Browsers and developers fight over features, and the standards become meaningless. “Works best in IE” and “Works best in Netscape” were common phrases seen on websites in the browser wars of the 90s. We’re not far off from having “Works best on iPhone” or “Works best in Chrome” become commonplace on today’s websites.

Everybody’s Complaining

This Webkit controversy has caused quite an uproar. Web developers are petitioning Microsoft, Mozilla, and Opera and asking them not to support the prefix. Co-chairman of the W3C’s CSS Working Group is warning everybody to stop this from happening. The Web Standards Project is asking all web developers to take action. All my favorite web gurus are voicing their opinions on the issue (Peter-Paul Koch, Eric Meyer, Remy Sharp). And there’s enough dramatic headlines to go around:

History Repeats Itself

While it’s the browser vendors who want to adopt this prefix, this whole mess isn’t necessarily their fault. If developers weren’t ignoring other browsers, browser vendors wouldn’t be doing this. However, if browsers had better standards support, developers wouldn’t be ignoring those browsers in the first place. There’s enough blame to go around.

What I found most fascinating is how Microsoft and Mozilla are handling the issue in the Webkit-dominated mobile realm. Two years ago, Microsoft tried to add support for a -webkit- property in Windows Phone 7. However, there was so much backlash that Microsoft reversed their position a day later.

An interview with Mozilla revealed that they’re considering adding -webkit- support in Firefox Mobile because websites are sniffing user agent strings for the word “Webkit” and ignoring non-Webkit browsers. They even showed a side-by-side comparison of Android’s default browser vs Firefox Mobile, showing the UA-sniffing in action with all the major websites (Google, Facebook, Twitter, et al.).

It’s interesting because history is repeating itself. Again. Back in the days when Mozilla dominated the market, Internet Explorer had to add “Mozilla” to their user agent string, since websites were UA-sniffing and disabling features for non-Mozilla browsers. When Apple launched Safari, they added “Gecko” to their user agent string, since websites were sniffing for Firefox’s “Gecko” engine and disabling features for non-Gecko browsers. When Google launched Chrome, they added “Safari” to their user agent string, since websites were sniffing for “Safari” and disabling features for non-Safari browsers. So, now that websites are sniffing for “Webkit,” Mozilla is going to change their user agent string to adapt, and they’re going to support some -webkit- properties as well.

Save the Web

As web developers, there’s not much we can do now, other than change our ways and try to minimize the damage that’s been done. Here’s what we should have been doing all along (and if you aren’t doing this already, it would help to start now):

  • When using experimental CSS (i.e., anything with a prefix), make sure to use all available browser prefixes, not just -webkit-. Look it up, add them yourself, use a CSS preprocessor, or use JavaScript to add them dynamically. It doesn’t matter how you do it; just stop being lazy and pay attention to other browsers.
  • Avoid sniffing user agent strings if you can. The only good reason I see for UA-sniffing is for detecting mobile browsers. If that’s your scenario, then make sure you’re paying attention to all the major browsers: iOS, Android, IE Mobile, Opera Mobile, and Firefox Mobile. Although, you’ll get major brownie points if you avoid UA-sniffing altogether and just use response web design instead.
Only time will tell how this CSS prefix debacle will affect the future of websites and web development, but let’s hope that for our sake, the damage is minor.