Compatibility mode expressed in response header
Niall Kennedy
page via a meta element or as a field in the response header.
http://msdn.microsoft.com/en-us/library/cc817574.aspx
Chrome Frame currently supports only the meta method, based on
available docs.
http://code.google.com/chrome/chromeframe/developers_guide.html#Making_Your_Pages_Work
Any plan to support site owners specifying support via HTTP header?
Providing a multiple key-value example in the docs should help
implementors (e.g. ie=8;chrome=1).
How will Chrome frames be versioned? If Google Chrome for Windows is
currently at a major version of 3, and Chromium at 4, what is the
meaning of your value of "1" (other than boolean?).
-Niall Kennedy
Alex Russell
On Tue, Sep 22, 2009 at 12:19 PM, Niall Kennedy <ni...@niallkennedy.com> wrote:
>
> The X-UA-Compatible flag introduced in IE8 supports declaration in the
> page via a meta element or as a field in the response header.
> http://msdn.microsoft.com/en-us/library/cc817574.aspx
Correct. Right now, we aren't supporting the HTTP header (although we
do support a separate MIME type, application/chromeframe) in part
because reading the network traffic isn't something we'd like to do.
We're actively looking at other ways of toggling the renderer, and the
<meta> tag solution is the most robust across all the various
solutions.
Depending on how it all goes, we might support the header, but there
aren't plans to right now.
> Chrome Frame currently supports only the meta method, based on
> available docs.
> http://code.google.com/chrome/chromeframe/developers_guide.html#Making_Your_Pages_Work
>
> Any plan to support site owners specifying support via HTTP header?
>
> Providing a multiple key-value example in the docs should help
> implementors (e.g. ie=8;chrome=1).
That's true.
> How will Chrome frames be versioned? If Google Chrome for Windows is
> currently at a major version of 3, and Chromium at 4, what is the
> meaning of your value of "1" (other than boolean?).
It's boolean for the time being. We won't be installing or allowing
multiple versions of Chrome Frame, so boolean is appropriate. Nearly
all users will eventually be on the Stable Channel Chrome Frame, so
setting a toggle for them wouldn't really help.
The good news here is that Chrome Frame auto-updates on the same cycle
as Chrome. Across the deployed base, there will be one version, and
it'll be continuously improving.
Regards
Sean Middleditch
it makes it possible to inject the header into statically served pages
using environment rules in Apache and other web servers.
I'm surprised the IE plugin API makes it easy for the plugin to
inspect the HTML document but not the response headers. I'd also
imagine that inspecting the HTML document for the META tag introduces
a good deal of overhead into the detection process, since any sane
plugin architecture (which very likely does not include IE's,
naturally) would allow a plugin to inspect response headers as they
are received or at the very least before any processing of the
document body has begun.
tazz_ben
does the right thing both when you have CF and not) meta value to have
is "ie=8;chrome=1" or "ie=7;chrome=1" (I have one app that renders
right in 8 mode, but is so much slower that I have it using the 7
engine). I'm always a little nervous with this tag because back in
the beta days it seemed to get thrown by things that shouldn't matter
(like spaces, if there was a tab between the head tag and beginning of
the meta tag).
On Sep 22, 12:45 pm, Alex Russell <slightly...@google.com> wrote:
> Hey Niall!
>
> On Tue, Sep 22, 2009 at 12:19 PM, Niall Kennedy <ni...@niallkennedy.com> wrote:
>
> > The X-UA-Compatible flag introduced in IE8 supports declaration in the
> > page via a meta element or as a field in the response header.
> >http://msdn.microsoft.com/en-us/library/cc817574.aspx
>
> Correct. Right now, we aren't supporting the HTTP header (although we
> do support a separate MIME type, application/chromeframe) in part
> because reading the network traffic isn't something we'd like to do.
> We're actively looking at other ways of toggling the renderer, and the
> <meta> tag solution is the most robust across all the various
> solutions.
>
> Depending on how it all goes, we might support the header, but there
> aren't plans to right now.
>
> > Chrome Frame currently supports only the meta method, based on
> > available docs.
Alex Russell
<sean.mid...@gmail.com> wrote:
>
> It's a LOT more convenient to use an HTTP header.
Trust me, I understand.
Like I said, if we can do this reliably in all the projected
situations we need to, we'll add it. For the first developer launch,
we haven't since we're still working out details. If you do
server-side detection of the plugin today (look for "chromeframe" in
the UA string), just send the alternate MIME type.
Regards
Alex Russell
>
> I just want to make sure about this. The most compatible (as in it
> does the right thing both when you have CF and not) meta value to have
> is "ie=8;chrome=1" or "ie=7;chrome=1" (I have one app that renders
> right in 8 mode, but is so much slower that I have it using the 7
> engine). I'm always a little nervous with this tag because back in
> the beta days it seemed to get thrown by things that shouldn't matter
> (like spaces, if there was a tab between the head tag and beginning of
> the meta tag).
If you have IE 8 handy, it should be easy to try out. The CF-side
parser should handle the ; delimiter fine.
Regards