Just Browsing

In Defense of Chrome Frame

Web technology’s pace of evolution is vexingly slow, the result of the wide range of browsers (new and legacy) that must support any innovation in order for it to take hold. Even back in the good old days (basically any time before 2005), when only the Netscape lineage of browsers and Internet Explorer were significant, it was still so hard for the two vendors to agree on anything that only a handful of significant improvements made it through: JavaScript and XMLHttpRequest are two obvious examples. CSS has certainly made its mark, but it has taken years for each release to gain widespread adoption (CSS level 3 is still “in development” after more than 10 years). XHTML, which offered huge advantages in terms of markup modularity and extensibility, was essentially stillborn because Microsoft made no effort to implement it in IE.

The situation is hardly likely to improve now that there are four major players in the browser space (Microsoft, Mozilla, Apple and Google). Bits and pieces of HTML 5 are starting to appear in production browsers, but the process has anything but speedy. The WHAT WG was set up in 2004, after all.

Is the future of the web doomed to be a tortuous succession of committee-driven specs that take years to achieve consensus and even longer to be implemented by vendors? Unfortunately, the answer is, to a large degree, likely to be yes. Thankfully there is an alternative path for innovation on the web, in the form of out-of-band browser technology such as plugins, Java applets and, yes, even ActiveX. XMLHttpRequest, after all, was originally an ActiveX component, and it has given new life to the web application space with the advent of Ajax. We may lament the proprietary nature of Adobe Flash, but would we be even this far is the development of a standard <video> tag (finally starting to make its way into the latest generation of browsers) if it weren’t for the phenomenal success of Flash video?

Which brings us to Chrome Frame. Google’s IE plugin has stirred up considerable controversy, including a predictable attack from the spin doctors at Microsoft. Recently, Mozilla top brass like Mitchell Baker and Mike Shaver have expressed their own reservations. In a blog post, Mitchell speculates that Chrome Frame may degrade the user’s browsing experience:

Once your browser has fragmented into multiple rendering engines, it’s very hard to manage information across websites. Some information will be managable from the browser you use and some information from Chrome Frame. If the Smart Location Bar in the “browser” doesn’t show the sites you’re trying to return to, then you need to find a way to open Chrome Frame and search there. Your “browser” can no longer aggregate information for you across websites. This defeats one of the most important ways in which a browser can help people manage their experience.

Shaver voices similar objections:

Running Chrome Frame within IE makes many of the browser application’s features non-functional, or less effective. These include private browsing mode or their other security controls, features like accelerators or add-ons that operate on the content area, or even accessibility support.

I spent some time playing with Chrome Frame, and it seems to me that Mitchell’s thesis does not jibe with the reality of how the plugin works. By replacing the content portion of the browser, Chrome Frame swaps out IE’s renderer with a faster, more standards-compliant alternative. But it doesn’t change any of the overarching browser user interface (the “chrome”, if you will). Bookmarks are still unified in a single place. The Smart Location Bar still draws from a single browser history database. As far as I can see, private browsing functions as expected. The limited facilities for “aggregation” provided by Internet Explorer, in other words, still work just fine.

Shaver’s concerns have more merit. Behavior inside the content page is likely to differ depending on the rendering engine used. I verified that this is the case with form autofill. Fields that were previously filled out in IE mode do not yield the expected suggestions inside Chrome Frame. I imagine that ongoing development may enable the Google developers to rectify some of these shortcomings (e.g. by using Microsoft’s APIs to tap into their database of form values and suggest form field values accordingly). But there is no denying that running a browser-in-a-browser entails some real drawbacks.

On the other hand, we have to weigh these against the potential advantages. Shaver contends that “If [users] want to keep using IE for sites that the site’s developers agree work better with Chrome — and we agree that the majority of sites are much better with a more modern browser than Internet Explorer — it is likely because of application behaviour.” I wasn’t able to find any hard data on this, but the anecdotal evidence I’ve heard paints a different picture. People don’t use IE because they are in love with the application’s functionality. They use it because their company requires it, some of their applications (especially intranet sites) rely on it or, most likely in my opinion, they simply don’t know any better. After all, only a tiny minority of normal folks can even explain what a web browser is.

Faced with a significant proportion of web users who have displayed a total unwillingness to migrate away from the archaic, broken browser that is IE6, Google had a few options. They could give up on using whizzy new browser features to develop new products like Wave. They could leave IE6 users out in the cold (and thus jeopardize the success of a product like Wave that depends on adoption by an entire group of collaborators). Or they could accept a slower pace of development due to the significant resources needed to get Wave to run in IE6. Seen in this light, the release of Chrome Frame is a brilliant and elegant move. There’s a decent chance that the same users that appear to see changing browsers as a scary or unfeasible proposition will be willing to install a new browser plugin.

Chrome Frame is not a perfect solution. But realistically it may be the best way for Google to continue to push forward innovation in the web application space without excluding the 25% or so of web surfers still using IE6 (and to some degree the even larger number using later IE versions). This is a huge whopping win, and small, potentially fixable inconsistencies in the way users’ form fields are autofilled pale in comparison.