Debugging a CSS Issue with IE9: Mötley Crüe Edition

If you want to master app compat debugging, then I really only know of one approach: practice. Find things that are broken, and then find out why. If you have to look too far for something broken, then you must be significantly luckier than I am!

Now, I prefer to listen to Mötley Crüe when I debug (or drive somewhere, or sit somewhere, or walk somewhere, or…), so it seemed only fitting that I would debug something for a member of Crüe while listening to Crüe.

Now, a while back, Nikki Sixx updated his website. And, of course, the first thing I noticed is that it doesn’t render correctly on IE9 when in IE9 Standards mode. It renders fine, however, in IE8 or IE7 standards mode, and it also renders fine in Firefox, Chrome, Opera, and Safari. So, I figured it must be something with the new rendering engine, and went about with the assumption that our code was broken.

I first took a look with the developer tools, and spotted straight away the following error message in the Console tab:

SEC7113: CSS was ignored due to mime type mismatch

Interesting – so, perhaps it’s not a bug in IE9? I’m still a bit leery, because the fact that it works with every other engine seems to indicate something wrong with the one failing engine. So, I had a look with the new Network tab to see what I could find out about the MIME type. Here is what I found:

Content-Type    text/css, charset: UTF-8

OK, so it is a CSS file, and it’s specifying a content type. So, I’m now perplexed as to what I am seeing. Of course, I’m not as conversant with the new developer tools, so I took a look with my old friend Fiddler just to make sure the headers are completely raw, and found this:

HTTP/1.1 200 OK
Server: Apache/2.2.11 (Fedora)
X-Powered-By: PHP/5.3.2
Last-Modified: Tue, 07 Dec 2010 19:19:31 GMT
ETag: 7d2160439e3d0b054b09b638c9516e70-gzip
Content-Length: 92090
Content-Type: text/css, charset: UTF-8
Cache-Control: max-age=600
Date: Tue, 28 Dec 2010 18:04:33 GMT
Connection: keep-alive
Vary: Accept-Encoding

Now, this all looks fine to my uneducated eye – it looks as if we are specifying a content-type, and it appears to me that it is the correct one. But that’s the key – I’m not completely conversant in the specifications! So, let’s learn the specifications…

If you take a look here, you can see precisely what you should have for the content type, and it’s in the format:

Content-Type := type "/" subtype *[";" parameter]

Wait a minute … the specification has a semicolon and the content had a comma – it looks like this web page is actually at fault, and every other rendering engine (including ours) was just being forgiving! Wow, IE9 appears to not be shouldering the blame here! (Though admittedly we are being a little picky, given that in the past we were letting that slide.)

Of course, just to make sure, let’s test things out. First I found the request and response in Fiddler. Then, on, I chose to right-click, Save, Response, Entire response… and placed a copy of the response on my desktop. Then, I went in to the file, and replaced that comma with a semicolon. Finally, using the auto-responder from Fiddler, I fed this modified response to test out the fix.

Voila – when the header is modified to comply with specifications, it works! IE9 is vindicated, and I have a fix for the web page which involves a single character to make it compliant with standards. Now that the heavy lifting of debugging is finished, the only remaining challenge is to find the person who owns this page and point them to the fix, and then we can go on with the show.

Updated 29-December-2010

Daniel15 ( points out correctly that I didn’t go quite far enough down that spec. While the semicolon instead of a comma is all it takes to get it working, it isn’t far enough to get it up to spec. Specifically, it shouldn’t be using a colon after charset. The spec indicates:

parameter := attribute "=" value

That should be an equal sign instead. So, to be more correct the header value should be:

Content-Type: text/css; charset=UTF-8

Thanks, Daniel! And, as John points out, this is a header, so the fix would be something configured on the server and not something the designer would have submitted.

Comments (10)

  1. says:

    thanks, that's a great way to showcase the Ie developer tools and IE9 render engine difference.

  2. Daniel15 <> says:

    I don't think it's just the comma; there's meant to be an equals sign instead of a colon. So, this:

    Content-Type: text/css, charset: UTF-8

    Should actually be this:

    Content-Type: text/css; charset=UTF-8

  3. Mark says:

    @ Chris Jackson yes, even with the comma replaced by a semicolon, you are still being forgiving. @Daniel15 is correct. On the same page where you got the Content type spec from is this:

    parameter := attribute "=" value

    So that colon after 'charset' should be an equals sign.

  4. John says:

    Umm… except the content-type part is usually sent by the web server. When was the last time you put a Content-Type line into your .css file? Not excusing the possible incorrectness, just want to make sure the blame is pointed in the right place.

  5. Ryan says:

    I think you are approaching this with the wrong mentality to say that the webpage/server is wrong and leave it at that.

    Since – according to RFC – a comma isn't part of a token, parsing should be stopped at Content-Type: text/css or the entire line thrown out as invalid.

    Either way should not cause a type mismatch. There may be problems when UTF-8 is read as ascii, but in a CSS file it is likely to not cause any issues.

    Remember, there are a lot of stuffed up websites out there. You will not get them all fixed. How you deal with errors is almost as important as how you handle the stuff thats not broken.

  6. cjacks says:

    @Anonymous: Oh, we certainly haven't left it at that. If we toss out the entire line as invalid then you end up having a MIME type mismatch, which then gets ignored for security reasons. See:…/mime-handling-changes-in-internet-explorer.aspx. So, we have a number of choices. First, we can approach the developer to see if they can modify the headers on the file and make it compatible with IE9 standards – what should be a relatively easy fix. However, we have no control over what they do, so they may choose not to respond. That leaves us with the option of dropping into a compatibility mode, which also works to resolve the issue (and which we can distribute via Windows Update) without the developer doing a thing. Since getting it working in 9 standards is relatively straightforward, we'd really prefer to help the site get their application working natively in that mode with those rules appled. The core value of having the compatibility infrastructure, though, is to be able to fall back to older behaviors that are more or less strict. The compatibility infrastructure in Internet Explorer is designed to help provide such choices from a technology standpoint, but the option of which technology solution to apply is a business decision.

    Since my job is to work with enterprise customers, I suggested the soltuion I would be most likely to advocate in the enterprise scenario. For a public facing website where I have no relationship or ability to locate the team that owns the servers, it's a different story.

  7. cjacks says:

    That was supposed to say "@Ryan" – my email came in as @Anonymous for some reason – sorry about that!

  8. Richard H says:

    Anyone care to offer up _how_ one might instruct httpd to send the correct content type header when delivering a CSS file.  I would guess this problem will affect a VERY large number of sites as one rarely manually alters such settings.

  9. cjacks says:

    @Richard H – it depends on the web server. On IIS, I repro (and subsequently fix) the bug by going into the MIME Types option in the configuration console. I have no knowledge whatsoever about configuring Apache, which appears to be what is running here. It is not the default configuration on IIS, and I have to assume (though I am absolutely not authoritative) it's not the default configuration on Apache either so presumably somebody made that modification.

  10. Greg Lambert says:

    Another great example of potential CSS issues – nice to see some real world examples

Skip to main content