In one single day the news about Google Chrome Frame has reached, I suppose, every web related company or developer. As posted before, I hope this plug-in will be adopted soon throwing away every other plug-in "record", thanks to its target: the most used, discussed, slow, and not standard, casa Microsoft default browser, Internet Explorer.
I have spent part of my precedent night sleeping testing this little revolution from Big G. and here there are first suggestions, impressions, results.
The Google Getting Started guide is a good lecture, but it is not enough.
The Making Your Pages Work with Google Chrome Frame is incomplete, and I will tell you why.
First of all, we need to understand that Chrome is a Runtime Embedded Browser plug-in, not a tag related one then, as Adobe Flash Player is.
Just add this tag to the top of the page: That's it!
is confusing and not that detailed info.
We cannot mess up IE default Trident engine with a completely different one as WebKit via Chrome Frame is. Different are also variables, if any, globals, if any, render itself, and the best case scenario is that everything will break up!
As summary, runtime browser switch is not truly a good practice, for both main page, or iframes, since the Chrome Frame nature is to change the entire browsed content and since it does not make sense to have such hybrid, non-sense, configuration between JScript and V8, Trident and WebKit.
That is still not it!
One more time, we need to thanks Google for all this effort but suggested solution is not ideal! (quick update: Alex Russel agrees, so the page is hpefully gonna change soon).
Chrome Frame is, so far, an Internet Explorer related plug-in which means that the external script will not do anything interesting with every other browser such Firefox, Opera, Safari, or Chrome.
Google truncates web pages (body tag) to make things as fast as possible but it is suggesting us a "slowdown without reasons" practice.
Do We Truly Need To Know?
I think IE support cannot disappear today, I wish it would, but that's not gonna happen. If we develop a cross-browser Web application/site is quite useless to understand if we are using the plug in or not, 'cause if Google Chrome will be supported, special features detections a part, the website will simply looks exactly as it looks in Chrome.
I cannot spot a single valid reason, except the Install Prompt for IE, to include that file but my crystal ball says that Chrome Frame is planning to be installed as plug-in in other browsers as well in a not that far future ... so one day maybe it will make sense to remove that script from conditional comments.
Server Side Chrome Activation ?
Not yet, apparently an header in the server with chrome=1 value is useless. I hope this is a temporary issue 'cause to avoid switch delay once Trident has been already started, the server side header could be the best solution. On the other hand, being Chrome a Trident plug-in, I think Trident needs to start before the plug-in can be activated ... uhm, hell problem!
Enabling runtime Chrome Frame via url, cf: as url prefix, I have tested Taskspeed and many others benchmarks realizing that if I had used Google Chrome the result would have been exactly the same.
The only difference is the little delay, not that little with extremely old hardware, when the meta tag is interpreted and the switch activated runtime, specially the first time.
Chrome Frame is in any case 100% WebKit and Chrome. IE features, included conditional comments, for both layout or script, attachEvent and friends or CSS expressions, are not supported.
While features such V8 multi tab threading is supported ... again, 100% Chrome.
I am prety much sure the reason this plug-in is not stable is the native OS integration nature of Internet Exploer.
Talking about IE8 we have Accelerators and other specific stuff that will probably not work with this plug-in, but personally I have never used them.
In the Jurassic IE6 case the Operating System dependency is more than hard, and so far it is the most problematic browser but right now I have never encountered a single problem with this plug-in and to make it stable as soon as possible we all need to install it and test it in every single page. This procedure will help Chromium team to better and faster understand possible troubles, if any, so let's contribute: in the worst case scenario we'll have a better Web experience thanks to Chrome overall stunning performances, standards and HTML5 support.
P.S. the Developer console in IE8 should be activatd before the switch, and not after, otherwise with this version it won't work!
ABS ... I don't understand why it did not work and what you have done is the same, I have just done a bit after avoiding problems with the opened tag.
every good developer which aim is to test trying to understand if a run-time switch, possibly injected via some library, could be possible.
Chrome Frame On By Default ?
double tweet - up to 280 chars tweets!