IE8’s Compatibility Mode – when to use it

After studiously (yes – studiously – considering how often you get bugged by the OS) avoiding upgrading my IE6 installation to anything newer, I finally heeded the update call and upgraded to IE8.  I think Microsoft has finally done something right with IE8 because it supports web standards much better in its default state. (UPDATE: IE8 is the worst P.o.S. *ever*.  I have found that it hangs within 2-3 minutes of loading a couple of tabs over 90% of the time). UPDATE 2: I found the culprit. The Flashget add-on is what was causing the crash.The other side of this coin, however, is that many, many websites which explicitly detect for IE and emit code (whether HTML or CSS or Javascript) specifically for dealing IE bugs and idiosyncrasies are now going to break, sometimes very badly.  Thus, IE8 has a “Compatibility View” button that reverts IE8 to behaving like earlier, less standards-compliant versions of IE, complete with all the quirks.

I’ve already noticed one particularly important instance where IE8’s Compatibility View is essential:  the Plesk 8.x management console.  If you do not turn on IE8’s Compatibility View, Plesk won’t work.

If there is a moral lesson to learn here, it was to avoid browser specific code at [nearly] all costs.  In other words, make it a point to NEVER detect for different browsers and put the onus on the browser creators to render standards compliant pages correctly.

In practice, avoiding browser detection is not possible 100% of the time, but because we make it a point to reduce the amount of browser specific code as much as possible, we are able to avoid having to detect for the browser in 99.99% of cases.  One best practice we adopt is to just rely on CSS quirks to get a page to render the way we want on IE.  In this case, the page would (theoretically) work on IE8 correctly because IE8 would, like any other standards compliant browser, ignore the IE5/IE6/IE7 specific quirks.  Even for complex javascript-driven pages, we have been able to reduce browser specific DOM code to only a line or two in the past (with the advent of AJAX libraries like jQuery, this should no longer be something to worry about).  It is actually very tough work to figure out how to do this reduction, but it was worth it because the resulting code is much easier to maintain.

Those developers who thought they were doing the right thing by detecting for IE and having their websites behave, serve content and run JS code differently are now faced with the prospect of seeing their pages break on IE8.  Tsk, tsk, tsk.

The good news is that going forward, you should not have to worry about browser specific coding anymore (or at least worry much much less) which should have always been the case from the beginning anyway.