I've said it before and I'll say it again: This is the life! Struggling for days with some obscure IE bug!
This time I've seen IE8 switching to compatibility view after an AJAX update of the DOM. The official KB article just says this occurs when the page that's trying to be rendered is invalid (or as they like to call it "designed for older browsers", which I can only assume means older versions of IE that are even less standards compliant). Or in this case, when it becomes invalid, because before the AJAX update, it is rendered in IE8 standards mode without problems.
The first step would be to find the validation error(s) that upsets IE8 Standard Mode so badly it feels the need to revert to IE7 Quirks Mode. As it turned out in the end, the first step would the first of two, and comprised 99.5% of the 8 hours I needed to fix the bug.
So, how do you check the page source in IE after the AJAX update? Remember that IE reverts to Compatibility view and reloads the page, so it is very hard to determine the generated source. Here it is suggested to turn of "Automatically recover from rendering errors with Compatibility View" in IEs settings. But I can't access these setting because it is locked by the administrator, so I tried to add the force IE8 rendering meta tag, because "The presence of an IE8 X-UA-Compatible tag / HTTP header (e.g. ‘IE=8’ or ‘IE=EmulateIE8’ + a Standards DOCTYPE) forces a page to stay in IE8 mode regardless of the auto-recovery setting value on the client".
For good order, we're talking about this tag:
<meta http-equiv="X-UA-Compatible" content="IE=Edge;chrome=1" />
Surprisingly (because it is documented to behave otherwise) or unsurprisingly (because it is IE), this doesn't help. In the same situation it still changes back to compatibility view. Same with IE=8.
What seems to help is to open the developer tools screen (F12) and switch back to IE8 Standards Mode. It remains in that mode even after reproducing the steps that would normally switch the browser back to compatibility view mode.
Upon validation I find numerous deviations from the XHTML 1.0 Strict standard, for which I will blame my colleagues, naturally. Step by step I solved these errors, devising one elegant highlight of behavioral separation after another.
E.g. I've replaced this:
<input type="text" ondrop="return false;"/>
<input type="text" class="preventdrop"/>
In HTML and js files respectively, of course. Additionally, ondrop is not valid in XHTML 1.0 Strict, so mimicking its behaviour as shown above is not only cleaner, but actually solves a validation error.
Another example was applying the Satay method for Flash, because the Flash snippet used was also not standards compliant. If I had more advanced needs in including the Flash movie, I could have used a jQuery Flash embedding library, e.g. jQuery SWFObject, but that would have been overkill in this case (I only have one Flash movie, and it is really small).
When I finally validate the page, there are no errors, it's valid XHTML 1.0 Strict. And of course, the compatibility view switching still occurs. I'm not surprised. Not even disappointed. I'm just developing qwerty shaped imprints on my forehead by banging my face into my keyboard...
I turn to a different approach, I start commenting out pieces of the HTML returned by the AJAX query, until the switching stops. Just to see if it can be stopped at all. After commenting out the entire reply it stopped. This confirms something is wrong in the reply. Then I try to comment out smaller and smaller pieces and finally this leads to step two, a:
that should be a:
Or (in this case) leaving out the span tag entirely when it has no content.
A collapsed span tag is invalid in XHTML 1.0 Strict. I know this. I've seen it many, many times before. In IE8 it tends to break alignment of all following elements. I've never seen it force IE into compatibility view mode before. And why didn't it turn up validating the page before? I might have pretty printed the snippets in my XML editor before pasting it into the validator. The editor would recognize it as XML and expand the collapsed span tag. But I can't tell for sure if that is what I did.