Compatibility View and Hard Asserts
Where did you appear from, Compatibility View?
Something very strange occured when I started viewing this site in the IE8 Candidate Release; for some reason, when I was moving from page to page, I sometimes managed to invoke Compatibility View. Thinking that this was just an issue with the CR, I didn’t bother investigating it. However this issue has crept up in at least , and less than two weeks ago, hidden in a post entitled, Compatibility View and “Smart Defaults”, we got clarificiation as to exactly what this behaviour is, and when we can expect it to affect us;
For the most part, we’ve removed assertions from our retail code. That said, there are particular code paths within the new layout engine where, should an error occur, the layout process can’t gracefully recover and we’ve kept assertions around these paths. In the IE8 Beta builds, encountering one of these layout “hard asserts” caused IE to display a blank page – the thought process being that it was better to show the user nothing at all than allow interaction with a corrupt or otherwise obviously incorrectly displayed page. We refined this experience further in the released version of IE8 by recovering layout “hard asserts” using Compatibility View. In other words, we believe that showing a page the way IE7 would have offers a better user experience than showing no content at all.
In short, when IE8 detects an error which, as we’ve seen, can be invoked by , the browser will fall-back to rendering that document (and entire domain) in Compatibility View. Note however, that this process only applies when you don’t force Standards Mode using either the META declaration or HTTP Header. If however, you do force Standards Mode in this instance, IE8 will display a blank page.
Firstly, it’s quite astonishing to think that it’s possible to invoke complete page blankness simply by using a combination of CSS properties. What’s more, the latter option of forcing Standards Mode is now being used as a pre-emptive measure by authors who, one way or another, have misunderstood the information published by Microsoft and are afraid of their sites being rendered by users in Compatibility View. Ultimately, the combination of forcing Standards Mode and utilising certain CSS property combinations is likely to have some disastrous effects. Secondly, by not forcing Standards Mode, an author is inadvertently introducing the possibility of their entire domain being rendered in Compatibility View, for the remainder of that browser session. This is simply another of the many irrational decisions made by Microsoft throughout the development of IE8.
Aside
Bug Testing
First off, let me expell some myths – a) IE8 is not fully CSS 2.1 compliant, b) passing Acid 2 does not mean a browser is fully CSS 2.1 compliant and, c) creating and passing 7000 or so of your own tests also does not mean you’re fully CSS 2.1 compliant.
If you’ve been keeping track of my , you’ll see there’s been a steady stream of additions to the list – it currently stands at 51 CSS bugs. This is, to some part, thanks to folks who wrote in about issues they’ve come across, which has meant many more bugs have been identified and logged on Connect. If you’re someone who has taken the time to write in and I haven’t been in contact yet, please bear with me; I’ve had a lot on my plate over the past few months, but I assure you I’ll get round to replying to you, and filing the issue if neccessary.
Comments are closed.