Most web developers will hopefully test their sites and applications in a variety of browsers. It’s probably fair to say that the older versions of Internet Explorer in particular can cause even the most experienced dev to tear their hair out with their differences in rendering behavior and implementation of various DOM APIs so it’s always been particularly important to test a site in older versions of the big blue E.
I think IE 9 and 10 have done a pretty good job of keeping to standards so I don’t think this will be such a big issue in the future (that’s not to say you shouldn’t test these versions) but there are still a heck of a lot of people using IE and IE 7 (yes that’s your parents and big corporates with huge hulking Windows XP based networks) which means testing these previous browsers is still important – I don’t think my clients would be too happy if a significant portion of their customers couldn’t access their site or application!
IE dev tools and testing previous versions
Since version 8, IE has contained an integrated set of development tools (available as a separate download for earlier versions) which amongst other features offer the ability to simulate older versions of the IE. This can give you a nice quick way to test how your site will function all the way back to good old IE 7.
To access this functionality hit F12 or right click inspect element on a page.
The below screenshot shows the development tools in IE 10:
But wait, what is the difference between Browser and Document mode and more importantly how accurate a simulation is this of earlier versions of IE?
First let’s discuss Browser and Document mode.
Browser mode and Document mode
Determining the mode used to render a page is quite a complex process – see http://blogs.msdn.com/b/ie/archive/2010/03/02/how-ie8-determines-document-mode.aspx
The following can influence the Document mode a page is rendered in:
- Browser and Document mode setting in the dev tools
- Conditional comments and HTTP headers
- Compatibility view list
- Doctype (or lack of)
You can force IE to render a page in a particular Document mode by using special meta tags or setting certain HTTP response headers. This might be useful for example in telling IE how to render content in a legacy intranet application where you don’t have control over the source and it displays better in IE7 Quirks mode.
It can seem a bit unintuitive and confusing that IE dev tools has two separate modes (which do overlap in functionality) but this split allows you finer control over how a page is displayed, the ability to override browser defaults and to test how a page would display in scenarios such as compatibility mode.
Compatibility mode is a way of emulating earlier versions of IE so a page displays properly – Microsoft maintain a list of sites that should be rendered in this mode and you can add sites to your own local version of this list in compatibility view settings.
OK back to our testing question let’s look at the differences between Document and Browser mode:
- Does not modify the user agent string that is sent to a web server
- Determines how mark-up will be rendered
- Will re-render a page if changed in dev tools but won’t make another request to a web server
Browser mode on the other hand:
- Modifies the user agent string that is sent to a web server
- Changes how conditional comments in html will be evaluated
- Determines the Document mode that will be used by default (see above)
Probably the main difference as far as we are concerned is the user agent string that is sent and the defaulting of Document mode. With default browser settings the user agent string that is sent to a web server from my Windows 8 machine and IE10 is:
Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0)
If I set just the Document mode to IE 7 then the user agent string will not change although a different rendering mode will be used.
If however I set the Browser mode to IE7 then the following UA string will be sent:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.2; WOW64; .NET4.0E; .NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729; InfoPath.3)
You can try this by using the network tab and examining the user agent header.
For example if you want to test a page with a doctype in IE7 standards mode you can set the browser mode to IE7 (the IE7 user agent string will now be sent) and ensure the Document mode is set to standards mode.
If you want to test how an IE7 user viewing it in compatibility mode would view the page you can set the Browser mode to IE7 and the Document mode to Quirks.
OK so we understand the importance of the Browser and Document mode but we haven’t answered how IE simulates previous versions yet so let’s look at browser sub systems now.
Browser sub systems
Your average browser is a complex beast and is made up of a number of subsystems such as:
- Network engine
- Security systems
- And many others
It will come as no surprise to learn that different versions of a browser have different versions of these components.
So does IE contain previous versions of individual subsystems to enable you to simulate earlier versions?
…however depending on the component in some cases kind of – it depends on the subsystem (and no I sadly don’t have a list).
One of the big things that is not simulated when you use the IE dev tools to simulate previous versions is security related changes. This makes sense because it would be a really bad thing if you could force the browser into an earlier security mode that contained various potential system compromising flaws. This means you will never get a 100% accurate simulation of how an earlier browser would process a page although this probably won’t affect the majority of scenarios users will be testing.
However, there are also some other components such as the DOM selection engine that although a later version, still contain the older code so it can be simulated meaning you are probably getting a fairly accurate simulation of how something might have worked previously.
Of course if every version of every component was shipped with each version of IE it would be a massive install, the maintenance would be a nightmare and there could be memory implications for loading previous versions of components.
All this however points to the conclusion that for a 100% accurate simulation of earlier versions of Internet Explorer you are going to have to use an earlier version of Internet Explorer.
So what to do…
Well I guess you could set up a number of virtualized instances allowing you to test every possible version of a browser but few teams are going to have the resources to do this and that sounds like a heck of a lot of work!
My recommendation would be to instead use a service like browserstack.com or spoon.net that contains virtualized versions of earlier browsers all nicely setup for you. These services are inexpensive and allow you to simulate many different browser versions (and even offer other browser options such as mobile devices).
Secondly it’s a good idea to review the compatibility cookbooks that Microsoft release when they ship a new version of Internet Explorer as these can assist in giving you a heads up of breaking changes: http://msdn.microsoft.com/en-us/library/ie/hh771831(v=vs.85).aspx
Thanks to IE team for assistance in this article.