I have spent part of my precedent night
The Correct Way To Set Chrome Frame
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.
Writing something like:
Just add this tag to the top of the page: That's it!is confusing and not that detailed info.
A meta tag is normally placed in the header one, top of the page, but as soon as developers read about "that's it" most of them tried to add via JavaScript this meta tag to switch engine: this is wrong.
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.
Accordingly, the best way to activate Chrome Frame is to put in the head tag, top of the page, and before whatever JavaScript action, the meta.
<!DOCTYPE html>
<html>
<head>
<title>Google Chrome Frame</title>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<meta http-equiv="X-UA-Compatible" content="chrome=1" />
... the rest of the page, scripts, css, whatever
That is still not it!
Detecting Google Chrome Frame and Prompting to Install
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.
The best way to suggest Chrome Frame is to put that external script in a conditional comment:
<!DOCTYPE html>
<html>
<head>
<title>Google Chrome Frame</title>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<meta http-equiv="X-UA-Compatible" content="chrome=1" />
<!--[if IE]><script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/chrome-frame/1/CFInstall.min.js"></script><![endif]-->
</head>
<body>
</body>
<script type="text/javascript">
document.body.appendChild(
document.createTextNode(navigator.userAgent)
);
</script>
</html>
If for some reason we are worried about how to know if IE supports the plug-in, all we need to do is this:
var cf = (function(i,ua){
return i<ua.indexOf("chromeframe")||i<ua.indexOf("x-clock")
})(-1,navigator.userAgent.toLowerCase());
// cf is true when plug-in is installed
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!
// this won't have effect so far ...
header('X-UA-Compatible: Chrome=1', true);
Update
To understand if the browser will be render the page via Chrome Frame we can use this snippet as example:
<?php
$userAgent = $_SERVER['HTTP_USER_AGENT'];
if(
strpos($userAgent, 'chromeframe') !== false
) {
// your cool standard layout for Chrome
} else {
// your crappy IE dedicated one
}
?>
My First Impression
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.
What's Next ?
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!
