I wanted to write an article about it but missed a few cycles to do it before. This morning, I read Mitchell Baker's and Mike Shaver's articles about it. I could not agree more with them but I think Mitchell and Mike are missing a point in both their conclusions... Let's look at the facts here:

  • Google Chrome Frame (I'll write GCF below) is similar, in nature, to the IE-tab add-on for Firefox. It adds another rendering engine to IE and under certain circumstances triggers it to render the document instead of the default builtin rendering engine of IE.
  • so download is done by IE, and rendering can be done by WebKit ; no wonder why the stats reported by the media are closer to Google Chrome's than IE's...
  • Users and companies sticking to IE usually have a good reason for that: they don't know alternative browsers exist, or they have corporate websites that use proprietary features of IE and they cannot get rid of it at this time for various reasons, or they don't have system privileges to install such an alternative browser. GCF will not help here, since these features will not be reachable from within WebKit. And if they have no idea about alternative browsers, it's very unlikely they will ever learn about GCF... Don't forget such a plugin is not triggered by the usual HTML suspects like the EMBED tag. When IE (the regular one, without GCF) encounters <meta http-equiv="X-UA-Compatible" content="chrome=1">, it's just unable to let the user know about GCF and offer to download and use it.
  • yes, yes, I know you can also prepend "cf:" to a URL to make it render by GCF. But links in GCF? Hey, automatically back to IE's rendering engine. Bah.
  • it's very unlikely that GCF is going to reflect all dynamic DOM changes inside its rendering engine back to IE's. So all IE add-ons based on the document tree will probably fail miserably. For the same reason, printing a document probably becomes a rather complex task unless GCF includes a stub printer driver acting as a proxy between IE and GCF's printing engine. As a matter of fact, the Print menu item in IE+GCF is now greyed out for documents rendered by GCF and the only way to print the document is a context-click in the viewport... Superb :-(
  • similarly, making all the usual dialogs of IE work correctly with a document rendered by GCF is probably doable, but really complex and painful: WebKit has to call back the IE layer to save passwords, or retrieve them to populate form data in documents it renders. It's a painful task to maintain such a bi-directional wrapper and evolutions of IE will inevitably impact GCF rather drastically. Only the address bar will be partially saved from that since download is always done by IE.
  • honestly, the meta tag above is ugly. It's the very same comment I made when I first saw Apple's meta viewport tag for iPhone-specific web pages (while we have CSS Media Queries in hand...). Let's suppose a site uses that tag because it's written in HTML5 and wants to let current-IE users visit using GCF. Now let's suppose - that's not only purely theoretical - that a future version of IE is HTML5-compliant. What will happen? The website's owner can remove the tag, and then legacy IE versions are lost, or keep it and modern-IE users are redirected to WebKit instead of the builtin rendering engine?!? That's non-sense. That's harmful. That's bad.

Globally, I take Google Chrome Frame only as a proof of concept. I do not think it's meant to reach a large user base; or if it does, it will be a good surprise even for Google themselves. It's partly here to attract people to Google Chrome but in my personal opinion, it's also and mainly here to show, at a time some at Microsoft openly wonder why they still maintain IE's core, IE can and should dump its proprietary closed-source rendering engine in favor of WebKit.