Let's face it, browser testing for Internet Explorer isn't on most developers' "Top 10 Things to do for Fun" list. Of course we were all doing our happy dances last year when Microsoft released The Countdown to IE6, but that doesn't mean the battle is over. We still have to test for IE7, IE8, IE9, and a multitude of possible combinations in between.
You see, in addition to variations between versions, developers must consider asymmetries between native installs and virtual machines, document modes, and browser modes (a feature intended to improve the browsing experience for IE users viewing sites built for outdated versions).
I recently spent some time brushing up on my understanding of how the browser, document, and compatibility modes function - both independently and together - and thought I'd report my findings.
The Compatibility View button
The Compatibility View button is a smart addition to IE, but sometimes I find myself wishing I had more control over it on a per-site basis. If it was designed to resolve problems with websites built for earlier IE versions, why does it appear on my standards-compliant, 2012 website?
Many times I've made the mistake of trying to figure out why something is rendering inconsistently, only to realize I'd been viewing the site in compatibility mode the whole time. If I can make that mistake as a developer, surely it's a common occurrence among casual visitors.
(Testing, testing, testing) x 6?
IE Developer Tools is undoubtedly an invaluable addition to the IE suite. It's important to be familiar with the two mode controls indicated in the image below.
In the tool's most recent release, these two settings allow you to test your site in 16 possible variations. Whoa. Testing for 3 IE versions doesn't look so bad anymore…
Working with U-XA Compatibility meta tags
Enter U-XA Compatibility meta tags. With this small snippet of markup, we can control the sea of seemingly endless browser/document combinations and boss IE around, a little.
So we add something like this to our site's header, paying specific attention to the content attribute:
meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"
In the example above, we're telling Internet Explorer to modify the document mode to render as IE7, but not the browser mode. The browser mode is responsible, however, for controlling the document mode. So even if you add the compatibility meta tag, a user can still override your settings by clicking the compatibility button if the meta tag content doesn't match their version of IE.
On the other hand, you could always use the controversial IE=edge method to eliminate the button altogether, but Microsoft advises against it.
Web Standards, IE, & the Future
Keeping all these various "modes" around might make true compatibility more difficult to achieve in the long run because ultimately, we're supporting old code. It'd be nice to see the compatibility button phased out in near the future, but until then… it's Internet Explorer à la MODE. Good luck!
0
Let's face it, browser testing for Internet Explorer isn't on most developers' "Top 10 Things to do for Fun" list. Of course we were all doing our happy dances last year when Microsoft released The Countdown to IE6, but that doesn't mean the battle is over. We still have to test for IE7, IE8, IE9, and a multitude of possible combinations in between.
You see, in addition to variations between versions, developers must consider asymmetries between native installs and virtual machines, document modes, and browser modes (a feature intended to improve the browsing experience for IE users viewing sites built for outdated versions).
I recently spent some time brushing up on my understanding of how the browser, document, and compatibility modes function - both independently and together - and thought I'd report my findings.
The Compatibility View button
The Compatibility View button is a smart addition to IE, but sometimes I find myself wishing I had more control over it on a per-site basis. If it was designed to resolve problems with websites built for earlier IE versions, why does it appear on my standards-compliant, 2012 website?
Many times I've made the mistake of trying to figure out why something is rendering inconsistently, only to realize I'd been viewing the site in compatibility mode the whole time. If I can make that mistake as a developer, surely it's a common occurrence among casual visitors.
(Testing, testing, testing) x 6?
IE Developer Tools is undoubtedly an invaluable addition to the IE suite. It's important to be familiar with the two mode controls indicated in the image below.
In the tool's most recent release, these two settings allow you to test your site in 16 possible variations. Whoa. Testing for 3 IE versions doesn't look so bad anymore…
Working with U-XA Compatibility meta tags
Enter U-XA Compatibility meta tags. With this small snippet of markup, we can control the sea of seemingly endless browser/document combinations and boss IE around, a little.
So we add something like this to our site's header, paying specific attention to the content attribute:
meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"In the example above, we're telling Internet Explorer to modify the document mode to render as IE7, but not the browser mode. The browser mode is responsible, however, for controlling the document mode. So even if you add the compatibility meta tag, a user can still override your settings by clicking the compatibility button if the meta tag content doesn't match their version of IE.
On the other hand, you could always use the controversial IE=edge method to eliminate the button altogether, but Microsoft advises against it.
Web Standards, IE, & the Future
Keeping all these various "modes" around might make true compatibility more difficult to achieve in the long run because ultimately, we're supporting old code. It'd be nice to see the compatibility button phased out in near the future, but until then… it's Internet Explorer à la MODE. Good luck!