It’s just data

Chromie Don’t Play That

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.

But perhaps I shouldn’t rely so much on external validation.

Put more constructively, if GCF mentioned application/xhtml+xml AND 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 love the SVG icon for this post!

Posted by Scott Johnson at

Hehe, me too.

Posted by Bob Aman at

I presume GCF doesn’t play at all with MathPlayer (which does mention application/xhtml+xml, and will happily allow you to serve your pages to IE).

Posted by Jacques Distler at

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?

Posted by Ryan Riley at

Ryan: I use javascript to wrap the SVG in script tags before letting SVG Web loose on my content.

Posted by Sam Ruby at

From the code, it looks like the MIME type is actually application/chromepage

Posted by Philip Taylor at

Interesting. This renders well in both Chrome and IE, but when I add cf: to the beginning of the URL, I can no longer see the SVG images, though I do see the rounded corners.

Posted by Ryan Riley at

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.

Posted by Sam Ruby at

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...

Excerpt from Justinsomnia at

anildash shared an item via friendfeed

Chromie Don’t Play That submitted by anildash...

Excerpt from MyBlogLog - anildash : New with me at

This Week in HTML5 – Episode 36

Topics this week include parsing, accessibility, security, semantics, video, and web forms....

Excerpt from The WHATWG Blog at

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.


Posted by Alex Russell at

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.


Posted by Alex Russell at

It’s lucky that web developers are always careful and conscientious and never start relying on undocumented unsupported features, and e.g. will never write pages with <a href="cf:..."> or suggest serving the new MIME type after some UA sniffing.

(Alternatively: Any functionality exposed by a browser will be used and relied on by content, so it needs to be carefully considered and designed regardless of whether it was intended to be used.)

Posted by Philip Taylor at

Hysteria over unsupported methods

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.

Posted by Sam Ruby at

SVG Open Keynote

SVG Open Slides. Despite bringing my Windows laptop.  Despite setting my display to 1024x768.  Despite arriving early.  Despite testing my laptop with the presentation equipment.  Despite all... [more]

Trackback from Sam Ruby


Add your comment