Redmond Review

WebKit and the Render Wars

Microsoft needs to consider adding WebKit to Internet Explorer, or it could suffer painful consequences.

• By Andrew J. Brust
• 03/06/2013

On Feb. 13, Opera Software, maker of the Opera Web browser, announced it would be ditching its own Presto HTML rendering engine and adopting WebKit. WebKit is the rendering engine first used in Apple's Safari browser and, after being open sourced by Apple in 2005, was adopted by Google for use in its Chrome browser. WebKit's growing momentum impacts all Web developers, but especially those on the Microsoft platform.

In the 1990s, Web developers had to test their markup on Netscape Navigator and Internet Explorer (IE). Eventually IE won out (it was even the official browser on the Mac, for a time), and developers could effectively target a single rendering standard. Firefox, Safari and, later, Chrome changed that, forcing developers to test their HTML on multiple browsers once again. But it's a fair bet that most developers would prefer a single standard. Opera's decision means that just such a single standard could emerge, and WebKit could be it.

At first blush, Web developers on the .NET Framework platform don't have much to fear from this. In fact, it could be good news, as their browser testing surface area may be reduced. But this is not good news for Microsoft, given that IE 10 is the default browser on Windows 8 and the exclusive browser on Windows Phone 8. If the Web at large targets WebKit and doesn't care about Trident (IE's rendering engine), that could disenfranchise Microsoft in the mobile market, where it's already seriously challenged.

The Last Straw?
Let's be clear: Opera's adoption of WebKit, by itself, is not especially significant, given that its market share by most accounts is less than 2 percent. But Opera's decision, in the context of other factors, helps WebKit immensely. Chrome's significant growth in market share, coupled with the dominance of Apple's iOS and Google's Android in the mobile space, has made WebKit a contender on the desktop and a champion in the smartphone and tablet space. Even the browsers on BlackBerry and Samsung's Bada operating system use WebKit; add Opera and it's a lock.

So while Opera is a small player, its decision gives WebKit majority control of desktop browsers and a near monopoly in the mobile arena. In last month's column, I explained how Google's Chrome OS and Chrome packaged apps pose a real threat to Windows. Both of those technologies are based on WebKit and Google's V8 JavaScript engine, which Opera is also adopting. So WebKit's new power makes Chrome even more feasible as a platform, threatening Windows that much more.

I wrote another column almost three years ago that's also relevant to this predicament. In that column, I explained that while Microsoft participated in the World Wide Web Consortium (W3C), a body that determines HTML standards, it did not have a seat at the table in the Web Hypertext Application Technology Working Group (WHATWG), the body truly calling the shots on HTML 5.

Many view the WHATWG as being heavily influenced by one Ian Hickson, a Google employee, who has also worked for Opera and Netscape. Interestingly, many of Hickson's proposed standards were promptly implemented inside WebKit, and made available through Safari and the WebKit nightly build. That process was hardly democratic, and it practically assured WebKit's status as the engine most compliant with the WHATWG's HTML 5 draft standards, leaving Trident, IE and Microsoft in the lurch.

Realpolitik Response
No matter the process, WebKit and its dominance are here now and quite real. So where does this leave Microsoft and the developers in its ecosystem?

For starters, any Microsoft Web developer not targeting WebKit as a primary rendering environment should remedy that policy very quickly; WebKit should now be at least as important to you as IE/Trident. And however blasphemous this may sound, Microsoft should consider standardizing on WebKit itself or at least embedding WebKit in IE to implement a compatibility mode for sites incompatible with Trident.

Adopting WebKit would allow Microsoft to contribute code to the project, thus wielding greater influence in the HTML 5 conversation. It would also keep Microsoft ecosystem developers more in the Web mainstream. And even if Microsoft continued to maintain Trident, it could do so with a more informed sense of HTML 5 compliance.

When Microsoft decided to embrace HTML 5, it should have committed to a frequent release schedule for IE to keep it highly competitive, especially on the HTML 5 front. Microsoft also should have protested the WHATWG's undemocratic process vehemently. Redmond did neither of these, and so put developers in its ecosystem at a disadvantage. Those developers should now take matters into their own hands by targeting WebKit to maintain their competitiveness. And Microsoft should follow suit.