Internet Explorer 11: “Don't call me IE”

This past week, Microsoft officially unveiled the first preview of Internet Explorer 11 for Windows 8.11. Doing so put to rest a whirlwind of rumors based on leaked versions of the much-maligned web browser. We now know some very important details about Internet Explorer 11, including its support for WebGL, prefetch, prerender, flexbox, mutation observers, and other web standards. Perhaps more interestingly, though, is what is not in Internet Explorer 11.

For the first time in a long time, Microsoft has actually removed features from Internet Explorer. The user-agent string has also changed. It seems that Microsoft has gone out of their way to ensure that all existing isIE() code branches, whether in JavaScript or on the server, will return false for Internet Explorer 11. The optimistic view of this change is that Internet Explorer 11 finally supports enough web standards such that existing IE-specific behavior is no longer needed.

User-agent changes

The user-agent string for Internet Explorer 11 is shorter than previous versions and has some interesting changes:

Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv 11.0) like Gecko

Compare this to the Internet Explorer 10 user-agent string (on Windows 7):

Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)

The most glaring difference is the removal of the “MSIE” token, which has been part of the Internet Explorer user-agent from the beginning. Also noticeable is the addition of “like Gecko” at the end. This suggests that Internet Explorer would prefer to be identified as a Gecko-type browser if it’s not identified as itself. Safari was the first browser to add “like Gecko” so that anyone sniffing for “Gecko” in the user-agent string would allow the browser through.

Any sniffing code that looks for “MSIE” now will not work with the new user-agent string. You can still search for “Trident” to identify that it’s Internet Explorer (the “Trident” token was introduced with Internet Explorer 9). The true Internet Explorer version now comes via the “rv” token.

Additionally, there are changes to the navigator object that also obscure which browser is being used:

  • navigator.appName is now set to “Netscape”
  • navigator.product is now set to “Gecko”

This may seem like a sneaky attempt to trick developers, but this behavior is actually specified in HTML52. The navigator.product property must be “Gecko” and navigator.appName should be either “Netscape” or something more specific. Strange recommendations, but Internet Explorer 11 follows them.

The side effect of these navigator changes is that JavaScript-based logic for browser detection may end up using these and will end up identifying Internet Explorer 11 as a Gecko-based browser.

document.all and friends

Since Internet Explorer 4, document.all has been an omnipresent force in Internet Explorer. Prior to the implementation of document.getElementById(), document.all was the “IE way” of getting an element reference. Despite Internet Explorer 5′s DOM support, document.all has remained in Internet Explorer through version 10. As of 11, this vestige of a bygone era has now been made falsy, meaning that any code branches based on the presence of document.all will fail for Internet Explorer 11 even though code that actually uses document.all will work.3

Another holdover is the attachEvent() method for adding event handlers. This method, as well as detachEvent(), have now been removed from Internet Explorer 11. Removing these methods is a means to short-circuit logic such as:

function addEvent(element, type, handler) {
    if (element.attachEvent) {
        element.attachEvent("on" + type, handler);
    } else if (element.addEventListener) {
        element.addEventListener(type, handler, false);

Of course, it’s recommended that you always test for the standards-based version first, in which case the removal of attachEvent() would yield no different behavior. However, the Internet is littered with bad feature detection logic and removing attachEvent() ensures that any code written in the above manner will use the standard version instead of the IE-specific one.

Some of the other features that have been removed:

  • window.execScript() – IE’s own version of eval()
  • window.doScroll() – IE’s way of scrolling the window
  • script.onreadystatechange – IE’s way of telling of listening for when a script was loaded
  • script.readyState – IE’s way to test the load state of a script
  • document.selection – IE’s way of getting currently selected text
  • document.createStyleSheet – IE’s way to create a style sheet
  • style.styleSheet – IE’s way to reference a style sheet from a style object

All of these have standards-based equivalents that should be used instead of the old Internet Explorer way of doing things. As with removing the other features, removing these means that cross-browser code that does feature detection for standards-based features should continue working without change.


It looks like Internet Explorer 11 could be the best Internet Explorer yet by a long shot. By finally removing the evidence of past mistakes, Microsoft is ready to take a place amongst the standards-based browsers of today. Removing old features and adjusting the user-agent string to not be identified as Internet Explorer is a rather unique move to ensure that all sites that work today continue to work. If web applications are using feature detection instead of browser sniffing, then the code should just work with Internet Explorer 11. For servers that are sniffing the user-agent, users should still get a fully functional site because of Internet Explorer 11′s excellent standards support.

A future without IE-specific code branches is near, and I for one am happy to welcome it.

Update (02-July-2013): Revised to mention that document.all is not actually removed, rather has been changed to be falsy.

  1. Internet Explorer 11 preview guide for developers (MSDN)
  2. Navigator Object – Client Identification (HTML5)
  3. Obsolete – Behavior of document.all (HTML5)


  1. Serban

    Thank for bringing this to light! I still don't get why they keep the 'Mozilla/x.x' part, nobody checks for that part anymore.

  2. Kyle Simpson

    I am highly disappointed in IE's decision to remove `script.readyState` and `script.onreadystatechange`. They were essential (though non-standard) to providing "true script preloading" capability. Instead of IE being ahead of the game in what I still feel will be the future of script loading (someday), IE is setting itself back. This is bad news.

    Yeah, yeah, I understand the bigger point, they want to remove any API surface that makes people do special stuff for IE. But this is a case where they've thrown the baby out with the bathwater. Very disappointing.

  3. Liam Carton

    Very sad to see the demise of such powerful features as document.all it is so much better and more powerful than the W3C's getElementById mess.

    Another step backwards.

    I cannot help but think that at some point in the future some idiot at MS will just throw in the towel and switch to chromium, like Opera have now done.

  4. David Storey

    Great article.

    It is not strictly true that IE 11 removed document.all. It has used a similar trick to what Mozilla first did with document.all (and later copied by Opera and WebKit), where it still supports it, but cloaks it. If you test for it, it will say “This is not the <del>droids</del>API you’re looking for” (ok, it doesn’t, it returns false), but if you just use it directly it will work. See

    I haven’t tested the others to see if they are truly gone, or if they’re just cloaked. I suspect it is on a case by case basis. document.all is still used in a bunch of places without fallback, so it is probably still needed. It is amazing how many legacy scripts are still on important sites.

  5. Louis St-Amour

    @Kyle Simpson - Just use script's new onload behavior combined with async or what have you. If you need more granular control than that, send the script as a string and eval it when you need it.

  6. Kyle Simpson

    I've written up why IE11's decision with `script.readyState` and `script.onreadystatechange` are hostile to performance and performance-flexibility, and petitioning IE11 to reconsider:

    @Louis St-Amour there's a whole bunch of reasons why XHR loading of scripts is insufficient, not the least of which is the still-not-ubiquitous CORS issue for cross-domain loading (like even from CDN's). Moreover, that technique often is slow enough to completely remove the performance benefits you were trying to gain.

    I've done many benchmarks on this, and for the more complex loading/execution profiles I run across, IE has always been more performance in its script loading than any other browser.

    IE11 signals a retreat back from that leading position, which takes us backwards. That's not a good thing, even if it is in the name of "standards". What's wrong here is that the standards have been ignoring this needed use-case for too long. But at least IE had an answer for awhile. Now we don't. That sucks. :(

  7. Jeff Walden

    Is document.all gone, or is it an object that's falsy? I would guess the latter, so that if (document.all) won't fire, but will work. (Falsy objects when converted to bool convert to false, when compared via == or != act as if they were the value undefined, and have typeof falsyObject === "undefined". Otherwise they act like normal objects, including that falsyObject !== undefined despite falsyObject == undefined.)

  8. Nicholas C. Zakas

    @Jeff - You're right, it's falsy now. Updating the post.

  9. Jeff Walden

    Minor typo in the update: "documnet".

  10. Thomas Hunter II

    Wow, so many people in here are hating on IE11's removal of non-standard features! I'm wondering if they all work for giant Fortune 500 companies who create applications running solely on M$?

    It's great that these items are being removed. If Microsoft wants to get these non-standard features added, they can take a proposal to the W3C and go through the usual channels. It's of no benefit to the rest of us if only one browser supports a certain feature.

    I've worked for a few massive companies, who painted themselves in the corner by relying on silly IE6 bugs, such as grabbing input fields by their `name` attribute instead of their `id` using getElementById(). Years later, those horrible monolithic applications would require hundreds of man-hours to update into something a newer browser could execute. Of course, they wouldn't do it, and the big company would require XP with IE6 or Virtual Machines for anyone who wants to do payroll. Removal of these non-standard features will surely help developers in the future.

  11. Mr Brock Peters

    If you don't want to be called IE then don't act like IE.

  12. Kyle Simpson

    @Thomas Hunter:

    "so many people in here hating..." WHAA?

    Only one commenter expressed outright disdain for the loss of these features. All the others (besides myself -- more on that in a sec) seem in favor or indifferent, if asking questions to clarify the accuracy of Nicholas' post. So where are you getting "so many people" from?

    Now, I am in my comments pointing out a tangible loss (in terms of performance and flexibility) that is an end-result of IE11's change. I support all the other changes they made, but I'm lamenting the downside.

    I think most of us agree that standardization is the right path. There's nuances and downsides to that effort, though, so it's worth at least evaluating what they are rather than blindly fawning over every standard move.

  13. Oscar Godson

    "If web applications are using feature detection instead of browser sniffing, then the code should just work with Internet Explorer 11."

    They "should", but they don't. I've already had issues on a couple sites. Work in IE9-10, Chrome, and Firefox, but get errors in IE11.

  14. Nicholas C. Zakas

    @Brock - that's kind of the point, it's not acting like IE.

  15. Teylor Feliz

    This is a great news! It is going to break a lot of crappy web applications that work only with IE but at the end of the day we all win. Hopefully, developers that use browser sniffing instead of feature detection can change the scripts before IE 11 is released.

  16. biker

    It's great news really. But in China, The IE6 is still breathing strongly, It's still a long way to come for web developers in China to enjoy this pleasure..sad..

  17. Mark Boas

    Note that although many parts of WebGL are supported, things like video textures are not. So, for example, libraries like Seriously.js (a real-time video compositor for the web) - will not currently work in IE11 preview.

    Here's hoping video textures make it into IE11 final!

  18. Lelala

    Pretty sure, the harsh speed on implementing WebGL is due a trigger from major game labels for requesting something like that, to bring 3D-gfx to browser games (as epic showed lately with Unreal Engine in the browser). Since Steam is getting more and more traction, MS is looking forward not leave any ground in this area...

  19. Natalia Vondunker

    but yet there is no support for webRTC.

  20. Ted

    IE11 is still a long way to the std. But the step is right.

  21. Danno

    Looks good. It appears IE will re-dominate the browser market as Windows 8 takes off and now that they are standards compliant, fast, and "just work" who will bother seeking out competing browsers? Good news for MS and developers that like a common browser, bad news for the other guys.

  22. Jay Tennant

    Well, this is great news! Though it doesn't affect me too much--I use javascript libraries to do all the feature/browser abstraction I need.

  23. Ron

    I hope it's better! 10 is garbage - at least on Windows 7 Ultimate x64. Constant lockups, tabs not working. I kept hoping for an update to fix it. Finally got a big update (~135MB) a week or so ago. Better but still too many problems to make it usable. Had to revert to IE9 for sanity's sake.

  24. vthriller

    > Safari was the first browser to add “like Gecko”

    Safari was not. Konqueror was.

  25. Mathew Porter

    I wouldnt be surprised if IE eventually shifts to WebKit. There are some really cool features and support, the addition OpenGL support and some nice touch features for multi input devices are cool to.

  26. Cheong

    As long as WebKit is partly LGPL, there's no chance for IE to use it as it directly violates the coporate policy.

  27. frankieteardrop

    isn't isIE() returning false for IE 10 already?

  28. Nicholas C. Zakas

    @frankie - not if you're using the user-agent string.

  29. Nik Rolls

    Funnily enough, jQuery – which should be doing feature detection 'the right way' – fails to correctly check for the presence of addEvent before using it, and is currently crashing on IE11 in some cases.

  30. Seriously

    "Past mistakes."

    Yes, IE has made a lot of mistakes in the past, but that's a loaded comment. A lot of the features being removed were developed either before or in parallel with other vendors before W3C standards existed. So the legacy versions of the code were not "mistakes" but simply just the IE way of doing them before standards existed. The problem was that it took so long for IE to catch up on all the W3C standards, not that they had legacy ways of supporting behavior before the W3C even took up those features.

  31. joolss

    Does anyone know if the document.documentMode property still works in IE11 and returns the correct version?

  32. Christian

    Thank you very much for this article! :D

  33. Christian

    Guys, here's the official MS article saying the same about the "Trident" token for detecting IE11 browser using javascript:

Understanding JavaScript Promises E-book Cover

Demystify JavaScript promises with the e-book that explains not just concepts, but also real-world uses of promises.

Download the Free E-book!

The community edition of Understanding JavaScript Promises is a free download that arrives in minutes.