First posted to MSDN on Dec, 31 2014

One of the questions I’ve been discussing a lot lately, both internally and with customers, is how to go about disabling the default Compatibility View for the Local Intranet zone. Customers really want to disable this option! But you certainly can’t do that at the expense of compatibility.

Why Disable Local Intranet Compatibility View?

I’ve heard a number of reasons behind the desire to disable Compatibility View for the Local Intranet. Sometimes, it’s because people are scared that we’re going to disable compatibility view in the near future. And I can certainly understand that fear. It’s mostly driven by articles like this: Document modes are deprecated Yeah, if I read that, I’d have a pretty reasonable expectation that they’re going away soon, if not already dead. But keep in mind the definition of the word deprecation. Deprecation isn’t removal – it’s disapproval. We recommend that you don’t use them going forward. But our intent is to give reasonable time to move forward, and to use a grandfather approach (which is generally our preferred approach) – old stuff should continue to work as long as is reasonable, but make sure you don’t create new old stuff . And you can see that principle in action in what we’ve already announced – that in Windows 10, we’ll no longer going to support Document Modes for the public Internet (which, by and large, doesn’t require legacy support, otherwise it wouldn’t be able to support other browsers) – but we will support them in the Local Intranet zone, when they are added to the Compatibility View L... . So, fear isn’t the right reason – there’s no dire need to recklessly careen towards a Compatibility View-free world. That doesn’t mean that it’s a good idea to double down on Document Modes! Quite the contrary – there are all kinds of reasons why you want to gradually get all of your sites to use Edge Mode, and certainly why you’d want to create new sites in this mode in the first place. These reasons include:
  • HTML5 just does a lot more stuff – you can make your sites far more engaging, reduce your dependency on plug-ins to achieve what is now in-box capability, and simplify development and maintenance
  • Modern document modes are faster – yes, even legacy document modes are faster when compared to the actual browser, but I’ve seen performance deltas between 2x and 10x when comparing IE5 Quirks against Edge when both are tested in the same IE11
  • HTML5 tends to be more terse, and the reduction in “bare minimum” HTML over HTML4, when multiplied by web usage and number of users, can lead to significant bandwidth savings over time – the kind of stuff you typically only care about if and only if you pay the bandwidth bill, so if you’re not that person, go have a chat with them
  • You can’t hire college kids today who “speak” Compatibility View – so you’ve got a long term developer problem. You have to train new developers how to write for the legacy web. You also have to find a way to retain developers while simultaneously asking them to let already obsolete skills become more obsolete. The end result is likely to be that you struggle to recruit and retain great developers
The list goes on and on, but these are the big reasons that I’ve seen resonate, and honestly, that’s typically enough to start the conversation. But, a desire to use a modern document mode isn’t directly a reason to disable Compatibility View in the Local Intranet zone. You can have a grandfather strategy while leaving this setting enabled – developers can simply opt in to modern document modes using X-UA-Compatible. So, why disable it then? Because experience shows that, even though developers can opt into modern document modes, by and large they don’t know that they can and should! And that’s where I recommend building a strategy to disable Compat View. If you are able to build and enforce policies that ensure that all new applications and significant upgrades choose modern document modes using X-UA-Compatible, then you don’t need to change this setting. If, however, you find that you’re creating new old stuff because you can’t enforce these policies, then this setting stops the hemorrhaging – any new apps are immediately placed into modern document modes, and you start creating new new stuff.

What Were My Options Without Local Intranet Compatibility View?

Obviously, the goal of Local Intranet Compat View isn’t to encourage new old stuff – it’s there to simplify keeping your existing stuff working. The encouragement is an unintended consequence, but the goal is still desirable. What some customers did in an effort to change this setting was to remove Local Intranet and then add in sites to the Compatibility View Group Policy Setting. The problem, however, is that this setting applies to top-level domain only. So, two things happen. First, you have to find all of the servers that you don’t use a fully qualified domain name to reach. Second, when you do use a fully qualified domain name, you end up getting your entire company. Most often, a customer would add mycompany.com, and suddenly this setting became the equivalent to adding the Local Intranet zone, because you’ve now added everything, and once again, any new site in this domain inherits Compat View. It’s just not configurable enough to be an effective replacement which addresses the primary concern – avoiding creating new old stuff. The alternative, then, was to go in to each and every site that needed Compat View, and add an X-UA-Compatible tag to these. Which is really the inverse of the default – instead of old-by-default/new-by-opt-in, you end up with new-by-default/old-by-opt-in. And, once you see it this way, it tends to drive an effort decision – choose the path that requires the fewest touches. Since most stuff is old, old-by-default tends to win. The other challenge is that management of legacy dependencies is distributed rather than centralized. (You can, now, at least centrally monitor these dependencies using the Site Discovery Toolkit , but modifying them remains distributed.) In short, you ended up with a couple of flawed options, which is why most customers didn’t chase this. But, there’s been a lot of Enterprise-focused changes in IE lately…

Using the Enterprise Mode Site List to Replace Local Intranet Compatibility View

In November, we released an enhancement to the Enterprise Mode site list which allows you to choose any Document Mode for your sites. The thought process initially was to provide help to customers who had made it off of IE8, but hadn’t gotten to IE11 yet. But then people noticed that this might be the replacement they’ve been looking for. For those of you unfamiliar with the feature, you can choose a Document Mode for any domain or path within that domain, so you get the granularity and manageability that Enterprises require. Note that the Document Mode behaves the same as the EmulateIEx setting in X-UA-Compatible. (Not sure why we chose to use a new syntax here.) So, if you ask for docMode=”9”, you’ll get IE9 Standards document mode when you have a standards DOCTYPE, and IE5 Quirks when you don’t. Similarly, if you ask for docMode=”7”, you’ll get IE7 Standards document mode when you have a standards DOCTYPE, and IE5 Quirks when you don’t. And, conveniently, that’s exactly what Compatibility View does! So, finally there’s a more manageable way to configure and contain Compat View! Ah, but there’s a catch – there are a couple of reasons why this may be difficult (for now): You can’t combine docMode and emie As currently implemented, you can’t combine a docMode selection with EMIE – and EMIE does rely on your ability to choose from among the 3 document modes that IE8 offered . So, if simply choosing IE7 docmode isn’t enough (because of enhancements to compatibility that Enterprise Mode provides ) you may need to continue using Compat View or use the X-UA-Compatible route. I’m trying to push to change this and have given all of the evidence I’ve collected in order to remove this constraint, but it’s important to acknowledge its current existence. You put yourself on the critical path to modernization The problem with putting the developers in control of modernization, which is what you had with Compatibility View, is that developers don’t know they’re on the hook to choose to be modern. But with this approach, the inverse is true. The Enterprise Mode Site List overrides any developer votes. So, if you configure docMode=”7”, then even if a developer adds an X-UA-Compatible for IE=”edge”, your docMode vote is going to win, and you block modernization! So, you need to ensure that you have processes in place to respond to developer modernization requests and quickly remove them from the Site List on demand. If you can’t accommodate this, then you become the problem! We’re not really sure what else

These are the two considerations we’ve come across so far, but it’s not even been two months yet, so it’s still early days. I think it’s potentially really interesting to remove the old-by-default configuration and I think we’ll win, and I’m super curious to understand what you discover if you find this to see if there is something I can advocate for you or some solutions we can come up with. Don’t hesitate to reach out to me either via comments here or the “Email Blog Author” link if you’re trying this and have experiences to share!

Make the Enterprise Mode Site List your To Do List

The other interesting side-effect of this approach is that it further consolidates your list of “dependencies on old stuff” – which you can then manage down gradually! Basically, it becomes your to-do list. Some sites are going to be removed from the list because they just plain go away. Some will be removed when new versions are done. But no doubt there are some that will continue to live on and yet don’t have a modernization plan. Now you have that information in front of you, and you can consider the business value of modernization versus the cost, both individually and in aggregate. You can do some hard thinking about your portfolio as a whole, and it truly becomes a to-do list as you charge towards what I hope is one of your goals: restoring technology agility by removing the shackles of legacy software.