Update March 12, 2019: Since this post was published, I’ve received some customer questions on the future of Internet Explorer. We are committed to keeping Internet Explorer a supported, reliable, and safe browser. Internet Explorer is still a component of Windows and follows the support lifecycle of the OS on which it’s installed. For details, see: https://support.microsoft.com/help/17454/lifecycle-faq-internet-explorer.
From time to time, I am asked by customers, “How do I ensure that all web traffic goes to Internet Explorer?” In fact, I was recently asked this question by someone trying to help a hospital. Now, I understand the scenario. In healthcare (as in many other industries), it’s often the case that you’re running with an extremely thin team. As a result, it can seem that using Internet Explorer be default for all situations is the “easy button” because, well, most of your sites were designed for Internet Explorer, so…just…always use it, ok?
In short, this seems like a deliberate decision to take on some technical debt. It’s true that most organizations have some technical debt lying around. (For example, if you’ve disabled User Account Control, require a 32-bit OS or 32-bit Office suite, or are paying for extended support for a legacy version of Java, you have some technical debt.) But this technical debt? Well, it’s different.
Creating technical debt by default
In the past, Internet Explorer was optimized for simplicity at the expense of technical debt. Looking all the way back to Internet Explorer 6, the very concept of “standards mode” vs. “quirks mode” comes from this “easy button” approach. All existing content (which had no DOCTYPE) would get quirks mode; you got standards mode by adding a specific DOCTYPE.
This, of course, had one little pesky problem: most people neither manually type HTML nor obsessively read the documentation to make sure they get the right DOCTYPE. You see, in the bad old days, you couldn’t just put in <DOCTYPE HTML>, you had to put in a full document type definition (DTD), and what you put in determined whether you’d get standards or quirks. So, it wasn’t just the presence or absence of a declaration, but also whether you put in a correctly formatted and properly chosen DTD, that would promote you to standards mode.
So, what really happened is that developer tools either added this in the skeleton code, or they didn’t. Which meant, if your tool didn’t add this in, you would get Internet Explorer 5 emulation (quirks mode) by default. Getting modern was opt-in because that was easier.
Fast forward, as Internet Explorer standards mode supported more and more standards, we decided not to just update the mode we called standards mode because, when we did, we risked breaking applications written for an older interpretation of the standards. So, with Internet Explorer 8 (IE8), we added IE8 standards, but also kept Internet Explorer 7 (IE7) standards. That meant, for sites in the Internet zone, it would default to IE8 standards, but, for sites in the local intranet zone, it would default to IE7 standards.
Another easy button.
As you can see, by going with the “technical debt by default” approach, we ended up in a scenario whereby if you create a brand-new webpage today, run it in the local intranet zone, and don’t add any additional markup, you will end up using a 1999 implementation of web standards by default. Yikes!
Enough is enough
When we introduced Enterprise Mode for Internet Explorer 11 in 2014, we made the very deliberate decision not to include wild card support. You must add all the sites that you want so that we don’t continue the chain of “debt by default” that was initiated back in 2001. But you’re probably even busier today when you were back then—if, in fact, you were working in technology in 2001, which many people weren’t!—so how do we do that without making you pay the price?
We had to simplify creating that initial blacklist (legacy by exception, not by default). First, we launched Enterprise Site Discovery so you could gather this data from your endpoints. We then enabled similar functionality from Windows Analytics Site Discovery so you could gather this data without needing to build a new set of infrastructure and processes. Once you have that initial list, it should be all downhill from there: simply remove sites as you modernize them.
By making it easy to take a blacklist approach (legacy by exception), we were finally able to move away from taking a whitelist approach (legacy by default).
Why shouldn’t I just keep doing what I have been doing?
So, why was it so important that we invert our approach to legacy? Because if we didn’t, you would end up in a predicament—and probably sooner than you think.
You see, Internet Explorer is a compatibility solution. We’re not supporting new web standards for it and, while many sites work fine, developers by and large just aren’t testing for Internet Explorer these days. They’re testing on modern browsers. So, if we continued our previous approach, you would end up in a scenario where, by optimizing for the things you have, you end up not being able to use new apps as they come out. As new apps are coming out with greater frequency, what we want to help you do is avoid having to miss out on a progressively larger portion of the web!
