The WebKit Lie and the Future of Web Standards

Last week, Apple CEO Steve Jobs published a bizarre public letter in which he attacked Adobe, one of his company's biggest partners. His charges against Adobe were many, and Jobs spared no ire in his description of Adobe's cross-platform development tools which, heaven forbid, would allow developers to more easily create applications that would run as well on competing platforms as they would on Apple's iPhone. I could write pages and page of text criticizing Jobs for this strange outburst. But one part of his letter really hit home for me, because it touches on a topic I've been mulling over for months. And that topic concerns no less than the future of the web.

This is an important topic because we're moving, ever more quickly, into a world in which most of the applications and services we consume are delivered via the web. As the web takes the place of traditional Windows applications, developers have new issues to confront around compatibility, connectivity, performance, and functionality. And these issues are aggravated by the fact that the web is an ever-moving, ever-changing target, with standards bodies and the special needs of industry trade groups to deal with.

Today's web is woefully inadequate from a technical perspective, and various parties have sought to improve matters by offering different solutions for overcoming the limitations. For example, companies like Adobe and Microsoft make proprietary runtime environments--Flash/AIR and Silverlight, respectively--that make the web more like Windows. And browser makers, for their part, are embracing web standards like HTML 5, CSS, and so on, though these standards are a mess in the making and are haphazardly implemented from browser to browser.

Apple, of course, uses the WebKit rendering engine in its Safari web browser, on both the desktop (PC/Mac) and on mobile devices (iPhone/iPod). In his letter railing against Adobe, Jobs said that WebKit is "widely adopted," is, in fact, used by "every smartphone web browser other than Microsoft's." While this isn't strictly true, and doesn't address the more diversified desktop market, he confused matters further by then stating that "Apple has set the standard for mobile web browsers." That is, it's not an "international standard;" it's "the standard by which other browsers are measured." (This is like confusing the terms "complimentary" and "complementary.")

I used to believe that rallying around a single web rendering engine made sense, and I had even called out WebKit as the possible "standard" around which this could happen. But as I investigated WebKit, and how it's implemented on different desktop and mobile browsers--Google Chrome and Apple Safari use it on PCs--I realized this was a mistake.

The problem is manifold. First, there's no such thing as a single WebKit standard, and each browser, on each OS platform, implements it differently. Second, WebKit isn't distributed like Internet Explorer is; if you use WebKit in your own products, you are responsible for keeping it up to date, so it's possible that users could have multiple WebKit versions on their PCs, all with their own update mechanisms. And finally, as browsers mature and take advantage of more of the underlying power of the PC, or whatever platform they run within, they can offer more power and functionality; but each browser, on each platform, would need to be independently developed to harness this power.

I began realizing my mistake about WebKit around the time that Microsoft started discussing its plans for Internet Explorer (IE) 9 last November. At that time, and then again at the time of the public preview release of the browser in March, Microsoft highlighted three main topic areas for this browser version--performance, hardware acceleration, and standards interoperability. But what most of the tech press focused on, for fairly obvious reasons, was the performance: There it was, in all of its hardware accelerated goodness, animating and rendering onscreen objects at a speed that put all other browsers to shame.

I was interested that Microsoft would continue advancing its Trident rendering engine to take better advantage of underlying PC technologies like Direct3D and hardware acceleration. But what really caught my attention was the company's notion of "standards interoperability," which has since evolved to a simpler term, "same markup." The idea is elegant and obvious in retrospect: Every web browser should render the same web markup (HTML, CSS, whatever) identically. It's not the rendering engine that matters, it's that they adhere to a new kind of standard that we don't yet actually have in place.

Today, that's not what happens. And, sorry WebKit fans, but that's not what happens within the realm of WebKit-based browsers either. In fact, depending on the sites you're visiting, WebKit-based browsers render the web differently to some degree, ranging from subtle to profound, and because WebKit is only part of what makes a browser a browser, the other differences can be even more problematic.

And now that Microsoft has played its hand and announced that it will be adding hardware acceleration to IE 9, competing browser makers will want to follow suit. Good luck, though, because each WebKit browser will need to handle this differently on each OS platform, mobile and desktop, effectively bifurcating the WebKit family of products even further. WebKit isn't a standard, it's a mess.

I'm not suggesting that IE 9 is the future of the web. But I am suggesting that Microsoft's plan for "same markup" is the right one, and it's the one that the web will need to follow so that, no matter which browser comes out ahead, users will always have a great experience, and one that isn't marred by strange differences between browsers. This plan also leaves room for competitive advantages, where each browser maker can innovate both within and outside of the rendering engine, adding value as they see fit.

For the web to become the overreaching computing platform, it needs to "just work." And for the web to just work, it needs a set of standards that actually make sense, not the ridiculous current standards tests--I'm looking at you ACID3 and SunSpider--that in no way map to real-world usage. (I've heard such tests described as "juggling in a canoe": Interesting to look at, but ultimately pointless.) Standardizing how browsers handle web markup is a much better plan than creating a single, commodity rendering engine, and it maps neatly to the way we expect other aspects of our computing environment--processors, RAM, network cables, and so on--to just work with our PCs, regardless of the make or brand. That it comes from Microsoft is, in many ways, simply coincidental. But it's the right approach. Let's make it happen.