Well, Google Chrome Frame has certainly taken the web dev world by storm. It’s almost as if people are fed up with Internet Explorer and welcome an alternative.
Many useful things have already been said about Frame. I’d like to add a few technical notes I haven’t yet encountered anywhere else.
When I was doing research I used one test page and constantly changed the
<meta> tags in the
<head>. The problem was that IE/Frame seemed to be caching not only the page, but also in which rendering engine it should be shown. Therefore a simple page refresh won’t help you here.
Fortunately Twitter user jdalton came up with a solution: simply append a pseudo-query such as
?123 to the page URL. That bypasses the cache and forces the browser to re-evaluate the
The official way of enabling Chrome Frame for a web page is adding this meta tag to the
<meta http-equiv="X-UA-Compatible" content="chrome=1">
This is of course IE’s own syntax, and it seems to suggest Chrome Frame ties into the IE pre-parser, which is also responsible for detecting and executing the IE meta tags.
Now what happens if you add two meta tags to a page? For instance
<meta http-equiv="X-UA-Compatible" content="chrome=1"> <meta http-equiv="X-UA-Compatible" content="ie=8">
It turns out that only the first is executed. So the example above basically means “Please give me Chrome Frame, but if it’s not there I’ll settle for IE8.”
Swapping the two tags, like this, says the opposite.
<meta http-equiv="X-UA-Compatible" content="ie=8"> <meta http-equiv="X-UA-Compatible" content="chrome=1">
Now it reads: “Please give me IE8, but if it’s not there I’ll settle for Chrome Frame.”
This will doubtlessly be useful; it allows you to carefully distinguish between people who have Chrome Frame installed and those who don’t, and it also gives you the option to switch on Chrome Frame only for IE7 and lower.
If we suppose every single IE user installs Chrome Frame (a rather tall supposition), why would anyone want to stick with IE8?
In all fairness, none of them are particularly important, although every once in a very great while these points could, in theory, be a reason to stick with IE8.
And of course the list with stuff that Chrome supports but IE8 doesn’t is much, much longer.
More serious is the fact that Chrome (Frame or not) does not support IE8 extras such as accelerators, web slices, and ARIA support.
I thoroughly like the Web Slices idea, although I’m lukewarm about accelerators. As to ARIA, that’s obviously very important, and the accessibility community doesn’t seem to be too taken with Frame.
So accessibility is actually an argument for sticking with IE8. Who’d have thought that only a few years ago?
Finally, Microsoft believes that Chrome Frame is less secure than IE, although Google claims the exact opposite. I have no opinion here — security is not my strong suit. Still, this question will likely be the most important one when it comes to actually installing Frame. Besides, I feel that Chrome Frame’s security should be compared not to IE8’s, but to IE6’s.
The big question of the moment is whether IE users, and then especially IE6 users, will install Chrome Frame to a meaningful degree.
As I said before, most IE6 users are trapped within that browser because the Intranet applications on their corporate network do not work in any other browser — not even IE7.
So in the end the decision lies with corporate sysadmins who either decide to update all browsers with Frame or not. On the positive side, Frame will not break any existing Intranet applications — if you leave out the
<meta> tag IE6 will continue to act as IE6. So there’s no danger of Intranet apps not working.
On the other hand, corporate sysadmins are not the most progressive of people, and they will certainly want to test Chrome Frame before allowing it on their networks. It’s there that the security question will come into play, and that’s something I can’t say anything about because I just don’t know.
All in all we’re in for some more interesting times on the browser front.
widthunreliable on Android?
I’ll be around at the following conferences:
Comments are closed.