First posted to MSDN on Mar, 04 2011
One of the most common questions I get while working with enterprise customers is: should I leave Compatibility View turned on for the Local Intranet zone?
We have an awful lot of guidance that seems to be pushing for standards, standards, standards everywhere, and this has a tendency to get customers a little scared – will this compatibility mode go away at some point, and am I just delaying the inevitable? I don’t want to finish a migration, and then have to go back and do it all again.
There are two forces at work, and my recommendation is ensuring you consider both when developing your strategy.
First, there is business value in adopting standards. Think about it – how many college hires do you know coming out with deep IE6 experience? If you are developing externally facing websites, you can’t afford to ignore modern, standards-based browsers – so my internal web developers must have a different skillset from my external web developers. There are benefits to leaving the past behind, including more efficient markup, less code branching, etc.
At the same time, do you really want to go back and revisit every single one of your web applications each time that you move your browser? Compatibility with your existing web properties is, after all, one of the core value propositions of Internet Explorer. Having to uplift your entire application estate each and every time standard change is an expensive and time consuming proposition, and while adopting the latest standards in general is a good principle to follow, adopting it for each and every application may not have a business case to justify that investment. You shouldn’t have to touch every single app every time you want a new browser, even if the standards changed.
So, my recommendation when moving forward to a new browser is the following:
Start with your policies configured to make the majority of your applications work without touching them
The default configuration for both IE8 and IE9 is to place the Local Intranet zone into IE7 compatibility, and this typically makes sense. More of your apps work out of the box this way, which means you can choose to invest in standards for the applications where there is business value in doing so, and not have to do so for all of them because you have no other option.
Tag your sites each time you touch them
Defining your heuristics to place more web sites into a more compatible mode is certainly a good starting point, but why should we have to guess at all? You’ll want to eliminate the guesswork, particularly as the compatibility infrastructure grows to support compatibility with more previous browsers. If you tell IE which rendering mode works best for you, then we can take on some of the burden of keeping that compatible.
Tag each of your websites, if you are touching them anyway, with the
X-UA-Compatible
header.
This metadata provides evidence for future versions of the browser as to what they could do in order to keep your application working better.
It is also important to know about this because, if you default to IE7 compatibility mode for all of your internal web sites, this is the one and only way to opt a site into more current implementations of standards! If you want to play with the significantly more HTML 4.01 compliance in the IE8 rendering mode, then you need to tag your internal site. If you want to leverage the full power of HTML 5 in IE9, then you’ll need to tag your internal site.
Providing metadata that gives evidence around your design – breadcrumbs, if you will – is always a good idea.
Implement standards for new apps and significant enhancements
Having compatibility with IE7 as the default is great for most existing application portfolios, but you don’t want to keep building dependencies on dated standards and implementations thereof, do you? I recommend putting a quality bar in place for new apps, or significant updates to existing apps, to require that they adopt at least IE8-level support of established standards, and possibly IE9-level support of emerging standards, so that your application estate moves forward – gradually, organically, and manageably.
The periodic drop of a new browser could result in an expensive manifestation of punctuated equilibrium, but by leveraging the compatibility infrastructure of Internet Explorer 8 and Internet Explorer 9, the enterprise can tame these periodic bursts of investment and better approach the phyletic gradualism that provides more predictable IT management costs. It is important to keep moving forward, embrace standards, and welcome interoperability – at a pace your business can afford.
