Alex Russell: Right now, we aren’t supporting the HTTP header (although we do support a separate MIME type, application/chromeframe)
The additional MIME type isn’t mentioned in the ACCEPT header.
Nor is application/xhtml+xml, so my pages are still served as text/html causing the SVG to not be rendered. And pages served as application/xhtml+xml still result in a Do you want to save this file, or find a program online to open it dialog.
Current tally: Google Chrome Frame violates HTML 4 by using http-equiv to specify something other than an HTTP header, it violates HTML 5 by using an unenumerated value for http-equiv, and violates RFC 2616 by not specifying the correct ACCEPT header.
Put more constructively, if GCF mentioned application/xhtml+xmlAND intercepted it, my site would “just work”. But that wouldn’t be an “opt in”, a concept that Ian Hickson once described as yet another quirks mode switch. Alternately, if they supported the HTTP header, I might be willing to consider coding all this in my .htaccess file. But failing that, and given that I have svgweb, I’m not predisposed to make all of my pages non-conforming at this time.
I’m a bit confused. I see you are writing in HTML5 with SVG inline but without apparently wrapping the SVG in script tags. All this amazingly still renders in IE8 without the tag for Chrome Frame. How exactly are you achieving this marvel?
yes, if you add cf:, a request is sent to the server that does NOT specify accept: application/xhtml+xml, so I sent back a response with Content-Type: text/html. Chrome currently only supports SVG in the application/xhtml+xml MIME type, but supports border-radius in both MIME types.
Sometimes I just LOVE Sam Ruby: Chromie Don’t Play That…
Sometimes I just LOVE Sam Ruby: Chromie Don’t Play That Current tally: Google Chrome Frame violates HTML 4 by using http-equiv to specify something other than an HTTP header, it violates HTML 5 by using an unenumerated value for http-equiv, and...
The only supported method for triggering GCF is the meta tag. Anything else is undocumented and not supported and not recommended. Hysteria over unsupported methods that developers can use for testing is as unwarrented as it is premature.
To expand slightly on my earlier comment (which was send from a phone and therefore perhaps too terse), when I said on the list that we “supported” the extra mime type, I chose the wrong word. GCF can today recognize “application/chromeframe”, but it’s not officially supported. It’s not documented for a reason. The meta tag is the only legit, supported way of invoking GCF today. And yes, it has all of the caveats and problems you flag.
As for supporting a real X-UA-Compatible header, it’s on the TODO list for investigation. We haven’t done it to date due to implementation concerns, not because we don’t believe it’s the right thing to do. Putting in a quick hack to turn it on and then having to walk it back later isn’t something we’re interested in, so we’ll add (documented) support for it iff we’re sure we can do it reliably.
I don’t see any hysteria here. Until your comment, I only included your parenthetical quote for completeness, and Phillip mentioned that the actual MIME type supported by the code differed.
The meta tag is the only legit, supported way of invoking GCF today.
We differ on the word legit here. To be clear: GCF, the codebase, is awesome. The way GCF interacts with and implements recognized standards, considerably less so. This may be a simple matter of documenting and registering a MIME type, an HTTP header and an http-equiv extension.
More specific to this blog, GCF will currently only display inline SVG images (such as the one found on this page) if the mime type is application/xhtml+xml. Not all browsers support this MIME type, so I only send it to browsers that indicate that they support the mime type via the ACCEPT header.
One final note, I would personally prefer a more loosely coupled approach, i.e., I would like to minimize the amount of browser sniffing I have to do. My pages are generally served as static HTML, with the HTTP headers being the only thing negotiated on demand. If I have to do any sniffing at all, I would prefer it to be based on browser capabilities rather than browser names. I’m OK with an opt-in approach, but would prefer any differences that such an opt-in approach implies be based on HTTP headers sent on a specific response, and not require changes to my payload which is sent to everyone.