Google last month launched a new open source project called Chrome Frame, a browser plugin that brings Chrome's powerful HTML renderer and high-speed JavaScript engine to Microsoft's browser. The plugin will allow Internet Explorer users to enjoy next-generation Web applications like Google Wave by providing critical performance improvements and strong support for emerging standards.

Despite the benefits that the plugin offers to end users and the Web development community, other browser vendors have some concerns about the implications. Mozilla and Microsoft have raised some valid questions about potential problems with Chrome Frame, but we're still not convinced that the plugin is a net loss for the Web.

The charge

Mozilla boss Mitchell Baker argues that injecting an alternate rendering engine into IE will create confusion and disrupt the browser's basic functionality in key ways. Even worse, she fears that it will lead to the proliferation of site-specific rendering plugins that will fragment the Web. Mozilla VP of engineering Mike Shaver also expressed concern, citing the multitude of problems created by existing browser plugins. In an interview with ComputerWorld, Shaver expressed concern that Google might even bring Chrome Frame to Firefox.

Mozilla developers have experimented with similar projects in the past with varying levels of earnestness. Mozilla's Screaming Monkey initiative, for example, aimed to provide a plugin for bringing Mozilla's JavaScript engine to Internet Explorer. Mozilla developers have also created an experimental IE plugin that injects Mozilla's implementation of the HTML 5 Canvas element. The Mozilla developer behind that project has suggested that the same technique could eventually be used for other key HTML 5 features such as video.

Although the scope of these plugins is significantly smaller than Chrome Frame, and they would theoretically be less disruptive to browser functionality, they still create many of the same problems and represent an equal contribution to what Baker disapprovingly describes as "browser soup." At what point does the breakage inherent in the plugin model outweigh the advantages of introducing improved support for modern standards-based, open Web features?

Worth worrying about?

I was somewhat puzzled by Shaver's comments about the possibility that Google might bring Chrome Frame to Firefox. He doesn't know if Google will choose to make Chrome Frame available for Firefox users in the future, and Google has done nothing to indicate that it will.

It's hard to imagine why Google would want or need to release Chrome Frame for Firefox, and it's such an improbable scenario that it shouldn't warrant real contemplation. Firefox is a modern browser with support for emerging standards and a reasonably fast JavaScript engine. Chrome's renderer may offer some advantages over Firefox's built-in renderer in a handful of specific contexts, but not to a degree that would necessitate the swap. A point that seems to be getting lost here is that the goal of Chrome Frame is to make Internet Explorer support standards-based features that are already in all other browsers, including Firefox. If Firefox is already conforming with those standards, why would Google need Firefox users to have Chrome Frame?

Shaver is concerned that Google could use Chrome Frame to push its own non-standard features or standards-based features that aren't widely implemented into Firefox and IE, thus creating the risk of Google lock-in by encouraging developers to code to features that aren't available elsewhere. But Google already has a plugin for bringing non-standard Web features to Firefox: Gears.

Gears allows Google to prototype new Web features and make those features accessible in its own Web applications. Google has largely used Gears as a proving ground for features that it wants to introduce as future Web standards. Mozilla has done similar things, like offering plugins for its early implementation of WebGL, which was later moved natively into the browser as it gained multi-vendor support through the standards process.

It's worth noting that Shaver is an enthusiastic supporter of Gears. If Google wants to experimentally introduce new non-standard features in Firefox, it can continue doing so with Gears while using Chrome Frame to push those features into IE along with support for modern Web standards. Mozilla has never objected to Gears even though it exhibits the same sort of problems as Chrome Frame, disrupting IE features such as Web Slices and Accelerators.

Ultimately, I don't disagree with Mozilla's underlying assertion that Chrome Frame breaks certain features of IE in ways that are undesirable. But those issues could potentially be remedied to an extent that would make Chrome Frame a tolerable solution. It's possible to identify where breakage happens and make the user experience more seamless. For example, one of the current problems is that Chrome Frame ignores the user's accessibility font settings; that's fixable.

I also strongly agree with Mozilla's assertion that the Web would be better off if we could encourage users to install a better browser rather than running a better renderer as a plugin. I don't think that the two approaches are mutually exclusive, however. There is no reason why Google can't encourage people to upgrade while providing Chrome Frame as a solution for those few who can't or won't. The plugin could even be helpful as a tool for gradually transitioning users to the full Chrome browser.

Browser vendors are all painfully aware of how plugins can degrade the user experience, so it's understandable that Chrome Frame would face a lot of trepidation. It's certainly worthwhile for Mozilla to be bringing up these issues, and I hope (and suspect) that Google values the feedback.

Still, I'm not convinced that the problems with Chrome Frame outweigh the fragmentation and deleterious effects that legacy versions of Internet Explorer continue to have on the market. Are you?

Further reading