If you are responsible for a commercial web site or web application, you understand too well that there are significant differences between web browsers.  Creating and maintaining a web site or web application that is truly cross-browser compatible is both a skill and and art.  And now there's a new browser on the scene:  Internet Explorer 8 ("IE8").

Just to keep web developers jumping, Microsoft decided to change the behavior of some extremely fundamental aspects of the browser.  For example, the "onresize" event is the notification event that applications rely on to determine when something in the browser changes size, e.g., when a user resizes the browser window, an application may need to do something to adjust for the new window size.  In its infinite wisdom, Microsoft decided to change the default behavior of this event.  Never mind that millions of web pages rely on the long established behavior as implemented by IE7 (and IE6, IE5, IE4, Firefox, Safari, Opera, Chrome, etc.).

Well, as it turns out, the new behavior could cause the MyST Blogsite editor to hang in an infinite loop.  (Technically, it was processing an infinite cascade of onresize events.)

Fortunately, Microsoft also added a "Compatibility View" feature to IE8 that forces IE8 to behave more like IE7—that is, to be compatible with the millions of web pages that were tested against IE7 but now break under IE8.  Unfortunately, they did not make Compatibility View the default.  In other words, the default is non-compatibility.  (Silly.)

After doing a little Googling, I ran across this article, by Aaron Gustafson, that provides a hint about how to force IE8 to use Compatibility View for a web page automatically, without requiring the user to mess with browser options.

X-UA-Compatible Header

Here's the magic.

IE8 recognizes a new HTTP response header that tells IE8 which browser(s) the web page has been tested against.  In other words, with which browser(s) the web page is compatible.  Specifying a value of "IE=7" means the web page is compatible with IE7 and causes IE8 to automatically process it using its Compatibility View.

Alternatively, you can specify the X-UA-Compatible details by placing an http-equiv meta element within the web page itself:

<meta http-equiv="X-UA-Compatible" content="IE=7" />

If you use the meta element approach, you must ensure that the tag appear early in the head section of the page.  Specifically, it can be preceded by other meta elements and the title element, but will need to be placed above any other elements—and you can’t add it into the DOM via JavaScript.

Once I added the meta element to the MyST Blogsite rendering framework (which is all XSL, so adding it was very simple), we were able to close all support issues related to IE8 compatibility issues.  And, I was able to stop pulling my hair out.