IE doesn’t have an emulation feature

“I felt a great disturbance in the Force, as if millions of voices suddenly cried out in terror and were suddenly silenced. I fear something terrible has happened.”

Document Modes in Internet Explorer are probably one of the most misunderstood features of the browser itself. The cause of the confusion doesn’t lie exclusively on the end-user either, Microsoft has shipped a Document Mode switcher in the F12 Developer Tools under an Emulation tab for a while now. As a result, it’s not uncommon for people to think that Internet Explorer 11 can emulate Internet Explorer 8 for the purposes of testing simply by switching the Document Mode.

“I have a very bad feeling about this.”

So what the heck is this feature? Why does it exist, and what should we call it if not “emulation”? I recently discussed this on twitter with a friend, and my frustration over the matter drove me to really sit and think about a proper way to illustrate the purpose of this feature. After some thought, I arrived at a comparison with an A99 Aquata Breather. You know what that is, right? No? Let me explain.

The A99 Aquata Breather (seen in Star Wars, episodes I and III) allowed Jedi to survive for up to 2 hours in an otherwise hositle environment. For instance, on their long-swim to the underwater city on Naboo Qui-Gon Jinn and Obi-Wan Kenobi used Aquata Breathers to stay alive long enough to enter the Hydrostatic Bubbles of Otoh Gunga (I really hope this is making sense…).

Lets bring this back to Internet Explorer and Document Modes. Just like Qui-Gon and Obi-Wan weren’t able to breathe under water (unassisted, that is), a site constructed in/for Internet Explorer 8 may not necessarily work in Internet Explorer 11 unassisted. So to ensure a more enjoyable experience, and avoid certain death, Jedi swim with an assisted-breathing device, and web developers send x-ua-compatible headers with their HTTP responses (or a meta-tag, if that’s your thing).

“That’s no moon. It’s a space station!”

So that Document Mode switcher in Internet Explorer’s F12 Developer Tools is not for seeing how well your modern site will work in a legacy browser, but rather how your legacy site will work in a modern browser.

Suppose a developer built an intranet application for her client in late 2009, when the client was running Internet Explorer 8 internally on a thousand machines. Several years later, the client calls the developer and informs her that they are planning on moving to Windows 8.1, and Internet Explorer 11. At this point, the developer can open Internet Explorer, navigate to the application, and see how well it will work for her client in a modern version of IE. Should she encounter differences in layout or scripting, she could switch the Document Mode to that of Internet Explorer 8 and see if this resolves the problem. (See also Enterprise Mode for IE)

Note the directionality — Document Modes are for making older sites work in modern browsers by creating (to some degree) environmental configurations the site relies on. This doesn’t turn the browser into an older version of itself; it merely satisfies a few expectations for the sake of the application.

“This is some rescue! You came in here, but didn’t you have a plan for getting out?”

Like the A99 Aquata Breather, a Jedi developer should only be expected to rely on a legacy document mode for a short period of time. The x-ua-compatible approach should be seen as a splint to keep your broken leg together until you can get some serious medical attention for it. It’s meant to keep you upright with the intent that you should be able to soon stand alone, unassisted. Don’t use a breather unless you’re swimming to a place that has air to breathe, and don’t use x-ua-comptabile headers or meta-tags without intending to fix whatever breaks your site in a modern browser.

If you develop in a modern version of Internet Explorer and do need to see how your site will render in an older version of IE, your best option is to download a free virtual machine from modern.ie, get an account on browserstack.com, or do your testing the next time you visit Grandma’s for dinner.

Emulation Accuracy in Internet Explorer

Early preview versions of Internet Explorer 11 lacked Emulation features that we saw in Internet Explorer 9 and 10. When Windows 8.1 shipped, Internet Explorer 11 was found to have the Emulation features shipped with it. These tools are helpful, though they can be misleading at times.

My general workflow in the past when using these tools goes like this: A user reports an issue in Internet Explorer x. I instruct the latest version of Internet Explorer to emulate the reported version. If I encounter the same issue, I can debug using the modern version of Internet Explorer. If emulation does not reveal the same issue, I need to load up a virtual machine, or use a service like BrowserStack.

The problem with these tools is that it’s not entirely clear where the line of reliability resides. To what degree this emulation replicates the native experience is unknown (to me, at least). Due to this, I’ve decided to do a deep dive into Emulation and see just how reliable it is, and in which areas.

Computed Styles

The first dive wasinto Computed Styles. Does Internet Explorer generate the same computed styles as IE10 and IE9 when it is emulating those versions? Surprisingly, yes. Granted, I’m running instances of IE10 and IE9 in a Virtual Machine (compliments of modern.ie), so that should be considered. Also other important thing to note is that this pass-through assumes Standards Mode.

The comparison tables are being maintained in a Google Docs spreadsheet. Click the preview below for the full view.

comparison.table

Window Object

My next focus was on cycling over enumerable properties on the window object and laying those out for comparison. A cursory glance of this next table will reveal that Internet Explorer 11 emulates the window object from IE9 and IE10 very well. Granted, there are some very clear examples of where it brought along a couple extra methods and properties.

comparison.table.window

It’s worth noting that this particular table had to be done a couple of times. Some of these members don’t attach themselves to the window object until certain actions are performed. For instance, this table is front-loaded with a bunch of BROWSERTOOLS members that are pushed onto the window object when various portions of the developer tools are opened. Other members, such as $0, don’t exist until you perform an action like selecting an element in the DOM Explorer.