IE7 fallback to IE6 Standard Mode when rendering CSS from cache

Question

I have this problem that I can't seem to find a solution for...

I have a page that renders fine with native IE7 (not the emulated one from IE9/IE8) on the initial load, but falls back to IE6 Standard Mode on subsequent requests that get served from the browser cache. IE7 knows how to handle multiple CSS classes like "div.class1.class2", while IE6 Standard Mode does not - therefore my page breaks on every visit but the first.

Here's how to reproduce it:

• open up IE7 (the real one, IE7 Emulated Mode from IE9/IE8 won't work!)
• go to hhttp://beta.upcload.com/widget/popup?garmentId=workaholicfashion-5276777&sid=
• on the initial visit, everything should look nice and dandy (for example the blue button, like in Chrome or FF)
• reload the page now, several CSS rules break, because the browser falls back to IE6 Standard Mode (NOT Quirks Mode, I checked that one! document.compatMode is still "CSS1Compat")
• clear the cache and reload, everything looks nice again
• repeat as often as you like

So it seems to be that when the files all get served from the Amazon servers, IE7 renders them just fine, including CSS rules that contain multiple classes. (for example "div.class1.class2") When you try to reload the exact same page with the exact same code, it somehow switches to IE6 Standard Mode (not Quirks Mode), which doesn't understand chained CSS classes and breaks several designs, for example the buttons. I tried adding several different Doctype / Meta headers but they all make no difference, currently the page is XHTML Strict valid and has a X-UA-Compatible IE=edge header, but still fails to render properly when loaded from cache. The only difference in the headers I could make out was the missing Content-Type header for Not Modified requests, but that shouldn't be a problem, right?

Oh and to top it all off, when I open this exact same page with IE7 on my local development server, it renders just fine, even after a reload! :/

Update

Alright, so I was finally able to reproduce it on the development server. The only thing that was different there was the "max-age" header, causing the browser to not cache anything locally. When I increased the cache time, IE7 started caching those files, too which again caused a break in design, once they were loaded from cache. So it must be a problem with files being served from cache instead of from the server.

Update 2

I narrowed it down to the CSS file. It seems, that IE7 either renders it with IE6 mode when it comes from the cache (ie. no Content-Type header) and with IE7 mode when it gets loaded from the server. (Content-Type: text/css) Does anyone have an idea why that would be the case? Maybe some malformed CSS rules? As a workaround I now add a random parameter to the stylesheet to prevent caching, which prevents IE7 from switching to IE6 mode, but even after removing all errors and warnings from the stylesheet the problem persists.

Answer 1

Not to long ago I experienced exactly the opposite behavior while supporting a legacy IE6 app.

Anyway, u use xhtml 1.0 strict doctype, that is a important start!

First-off: the usual checklist:

• (Generated)(X)HTML files/data are sent/saved without BOM, not a single byte is before the DTD?
• Have you checked what settings are sent by the server that sent the file?
• Is the documents content type 'text/html' or XML ('application/xhtml+xml' or 'application/xml') (in markup-source = meta tag and/or sent by the server = header)?
• Is the page served from (or communicating with) a domain on the Microsoft Blacklist (where IE fallbackmode's are dis-allowed)?
• Have you checked for differences in IE's security settings between lan/intRAnet and wan/intERnet (since you mentioned different behavior)?
• Is there possibly a proxy through which you connect too the internet (that might rewrite something?)

Now have this data ready and visit the absolute best source on browsermode-switching I have EVER seen, in fact every self respecting web-dev book should cover this in the First chapters. All this goodness on one clear page, it's 'enlightening' to say the least..
People should know there are 2 parts to browser-mode switching and understand when to expect what kind of behavior.
On the same page you also find a IE mode-switching-flowchart that gives insight in the EXTENSIVE maze that IE follows to determine it's final rendering/browser-mode.

Really hope this helps!

UPDATE:
THERE IS NO IE6 (standard/quirk) mode (in newer versions of IE). See the official microsoft documentation (and updated link with this quote) !! Let me even quote it:

Windows Internet Explorer 7 offered new features that were designed to more fully support industry standards, such as support for the universal selector. Because the directive only supports two settings (quirks mode and standards mode), IE7 Standards mode replaced Internet Explorer 6 standards mode.

And here is the code for their doctype-switch checker (source on same page):

engine = null;
if (window.navigator.appName == "Microsoft Internet Explorer")
{
   // This is an IE browser. What mode is the engine in?
   if (document.documentMode) // IE8 or later
      engine = document.documentMode;
   else // IE 5-7
   {
      engine = 5; // Assume quirks mode unless proven otherwise
      if (document.compatMode)
      {
         if (document.compatMode == "CSS1Compat")
            engine = 7; // standards mode
      }
      // There is no test for IE6 standards mode because that mode  
      // was replaced by IE7 standards mode; there is no emulation.
   }
   // the engine variable now contains the document compatibility mode.
}

Now READ the comments in microsoft's code above!!!!

About your second update:
good find about the caching! So the css is the problem now. Since you now start to understand why legacy IE6 apps need IE6 (the reason why IE6 is so hard to kill), maybe you should look at conditional comments. Since:

• they are no hack (but as SDC has pointed out in the comments, Microsoft dropped them from IE10 on and forward)
• no javascript browser-sniffing (even no script NEEDED to be enabled, so always works),
• and it CAN specifically target (a range of) versions of IE Exclusively.

In them you could contain a link to a IE specific css (keeping the document small, lean and uncluttered)...