A build of Windows–codenamed Windows Blue–was leaked onto the internet recently. What does this tell us about what is coming in IE11?
First a disclaimer: the information in this post all comes from public sources. I have not run the leaked build myself, and although I am helping Microsoft with the userAgents community, I have no inside knowledge of current or future plans for IE11. This post is a distillation of these various posts, and my personal opinion or speculation.
A new identity
The first news about IE11 was that it has a new user agent string:
Mozilla/5.0 (IE 11.0; Windows NT 6.3; Trident/7.0; .NET4.0E; .NET4.0C; rv:11.0) like Gecko
There are two significant changes to this string:
- MSIE has been replaced by IE
- A like Gecko token has been added
The former is clearly to avoid getting the code branch designed for IE when sites use browser sniffing (a practice that causes untold damage). These are almost certainly designed for older versions of IE, such as those that don’t support addEventListener or other standards-based features. IE is saying it no longer wants legacy IE code. It wants standards-based code.
The latter has caused some confusion. It was reported that IE is pretending to be Firefox. This is only partially true. It is correct that Gecko is the name of Firefox’s rendering engine, but like gecko was the token added by WebKit. The reason why WebKit added it, and now also IE, is sites often didn’t say “do you want the IE-specific code or the standards-based code?” They often instead said: “Are you IE or are you Gecko?” It is not a question of if you support the standard, but if you are called Gecko. Even though WebKit is widely popular (as is IE), these sites and practices still persist, so the token is still needed. IE is basically taking a page out of WebKit’s playbook, which is asking for the Gecko branch. What IE will not get with this string is the sites specifically sniffing out WebKit. I suspect it doesn’t want these, as these code paths probably often include WebKit specific code or prefixes. Especially on mobile sites. Pretending to be Gecko gives less risk of vendor specific code, as it is not a reliable way to detect just Gecko-based browsers due to WebKit making the same move.
Changing the UA string is not the only way current builds of IE11 are cloaking their identity. The appName property now returns Netscape rather than Microsoft Internet Explorer. WebKit and Gecko already do this. IE and Opera/Presto were there only ones that didn’t identify as Netscape, but as the latter is switching to Blink, everyone is now Netscape.
Finally on the identity front, IE11 is now cloaking support for document.all. If you use feature detection to detect support for this feature, IE, like Firefox, WebKit, and Opera, will say false. Why? Isn’t object detection the holy grail? Yes, but, developers were ::drumroll:: using object detection to browser sniff. What? While working on Opera compatibility, I’d often (more times than I can count) see code like this:
var isIE = null;
if (document.all) {
isIE = true;
}
if (isIE) {
// do some crazy IE specific stuff with ActiveX, or filters or so on
} else {
// use standards based code
}
Now all of a sudden, if you support document.all, you are obviously IE and want to use totally non-related code. Cloaking support for document.all avoids this.
The other possibility is to remove support entirely, but sites would often use it without testing for support, and not have an alternative path, leaving sites broken. Cloaking generally gives you the best of both worlds, and is now an ubiquitous practice amongst browser vendors.
Update: IE11 now cloaks support for the ActiveXObject object, almost certainly for the same reasons as already outlined.
You have to bear in mind that all these changes happened in a leaked build of IE11. It could be that the developers are just experimenting to see if the identity changes break more than they fix. It should not be held as gospel that these changes will make it into the final version of IE11.
There is one key significance to all this. Microsoft is telling the world; IE has grown up, it is standards compliant and is capable of supporting the standards branch on sites. We no longer want the IE code paths.
I’m inclined to agree. IE10 is a huge step forward, and IE11 probably will be able to go toe to toe with the competition in terms of standards support.
ES6 support
A few features from ECMAScript 6 (the next version of JavaScript) appear in the leaked builds:
__proto__
The __proto__ property was non-standard, and looks really ugly to my eyes. It references the prototype of the object. The spec represents this as [[Prototype]], but there was no standards-based way to access this. ES6 changes this by standardising __proto__.
IE11 now supports this feature, along with Firefox, WebKit and Opera.
WeakMap
A WeakMap is a key/value pair map, where the key is an object, and if there is no longer a reference to the key object, it will be available to be garbage collected. Due to this behaviour, WeakMap keys are not enumerable. One specific use case for WeakMaps is to keep references to DOM nodes. When a DOM node is deleted from the document, it can be garbage collected and thus automatically removed from the map. This can reduce memory requirements.
Support for WeakMap is included in IE11, Firefox, and behind a flag in Chrome.
Update: Set
Support for Set objects has appeared in the latest leak. A Set holds a collection of values, but unlike data structures like an Array, a Set can not contain duplicates. For an excellent look into Set objects, check out Nicholas Zakas’ blog post ECMAScript 6 collections, Part 1: Sets.
Support for Set includes IE11, Firefox, and Chrome (behind a flag).
Update: Proprietary Mozilla APIs
Along with __proto__ which was until it was recently standardised, was a proprietary Mozilla invention, IE11 has added support for __defineGetter__ in the latest leaked build. This is a legacy feature, which has been standardised as Object.defineProperty in ES5. Why add a legacy feature when there is a standard that replaces it? One reason: compatibility. There is a bunch of code out there that uses __defineGetter__ without a non-legacy IE fallback. One of the reasons Opera added __defineGetter__ is that some frameworks and sites (Atlas being one I remember) would use it to add functionality.
In the case of Atlas it implemented everything using legacy IE API, and the “standards” based path was basically a polyfill for Firefox using __defineGetter__ to implement those APIs. If you didn’t support it, you just received a broken site. Now, that was a pretty backwards was to develop, but the feature was (and probably still is) used extensively. I suppose the IE team are seeing similar issues to the Opera team did, especially now they’re changing the UA string and cloaking support for legacy IE features.
WebGL
If there was ever a poster child that trolls and haters would use to claim IE is still not a modern browser, it would be WebGL. I’m personally not convinced it is the most important feature for the average web developer, as it is a complex technology to learn and use, and the average web site generally doesn’t need 3D graphics.
On the other hand, where WebGL is useful, it is often critical. Games are an obvious example. With the recent announcement by Mozilla and Epic of porting the Unreal 3 engine to JavaScript with asm.js, the Web’s credibility as a gaming platform is only going to increase. It is going to become more important that Microsoft has a solution in this space.
The good news is that implementation of WebGL in IE11 is underway. It has to be enabled with a registry tweak, which isn’t all that surprising considered its unfinished state. There was initial confusion that it only supports IESL shaders (from DirectX), rather than the GLSL format defined in the spec (which has its roots in OpenGL). Fortunately that is not the case, and it is possible to get WebGL demos running, even at this stage.
However, it is important not to get ahead of ourselves. Until it appears in an official build it does not mean it is certain to land in IE11. Anything from the feature not being complete on time to security concerns could mean it is not included or disabled by default. I remember at Opera that WebGL was initially turned off as it was possible to blue screen of death Windows by visiting a page with WebGL content (I think due to issues with shaders). Safari also currently has WebGL disabled by default. However, if Microsoft are implementing WebGL, I’d be very surprised if the plan isn’t to include it.
Networking
The currently leaked build of IE11 has evidence for SDPY support, although it is not currently functioning. As such you should be especially careful about assumptions it will appear in any final build of IE11.
SPDY is a networking protocol originally proposed by Google, built on top of HTTP. Its main goal is to speed up page loading by reducing latency, compressing headers, and reducing the number of connections per client. While it is not a standard, it is being used as the starting point for a future HTTP 2.0 standard from the IETF.
SPDY is supported by Opera, Firefox, and Chrome, and looks like it will be coming to IE11.
DOM and JavaScript APIs
Mutation Observers
Traditionally if you wanted to monitor DOM changes you would listen for DOM Mutation Events. It is widely acknowledged that the design of Mutation Events is flawed, due to inherent performance issues. Because of these problems, Mutation Events are now deprecated.
As the functionality of Mutation Events is important, there is a glaring need for a replacement. Step up DOM4 Mutation Observers! IE11 includes this feature, joining Chrome, Safari 6, and Firefox. Opera will inherit support once it switches to Blink.
Full Screen API
Sometimes it is desirable to make a web page cover the entire screen, hiding the browser chrome. Playing videos is probably the most common use case, but gaming would be a close second. The Full Screen API enables this functionality.
IE11 looks like it is implementing this spec, with the requestFullscreen method currently supported in leaked builds. it is prefixed with the ms prefix. Presumably the rest of the spec will be implemented in future builds. The spec is also supported unprefixed in Opera, and prefixed in Safari, Chrome, and Firefox. Firefox currently supports and older draft according to caniuse.com, as does Safari 5.1 and Chrome 15–19.
Update: CSS
Flexbox syntax update
The good news is that Flexbox in IE11 has been updated to the latest version (and most likely final) version of the spec. The Flexbox syntax changed just before IE10 was released, so it supports an outdated syntax. I was hit by the same issue when writing the flexbox section of SmashingBook 3. The new syntax is currently supported by Opera 12.1, Chrome (prefixed), and is coming to Firefox in version 21. Safari (and current Firefox) still supports a version of the spec older than the IE10 version.
CSS Level 4 Selectors?
There is preliminary support for CSS Level 4 Selectors in the latest leaked builds, but they are currently non-functional, and I don’t know which are included. I’m looking forward to seeing an update to François blog post to see what they are.
No browser to my knowledge has extensive support of the new CSS Level 4 selectors, except those moved in from CSS 3 Basic UI. The spec itself is relatively immature.
transform-style: preserve-3d?
According to François Remy’s post referenced above, there is also preliminary support for transform-style in the latest IE11 build, but preserve-3d does not work yet. Presumably the plan is to have this supported (to the relief of authors of sexy demos everywhere) by the time IE11 ships.
What’s next?
Your guess is as good as mine at this stage. I can say what I’d like to see however. Adding support for transform-style: preserve-3d makes sense to round out 3D capabilities (Update: looks like this is underway). I’d love to see support for @supports from CSS Conditional Rules, as the sooner it is implemented cross-browser, the more useful it becomes. When I worked at Motorola, I pushed for this to be implemented by the WebKit team there, and it has now landed in WebKit. It is also supported in Firefox behind a flag, and in Opera 12.1. Support for border-image would also be nice. Additional codecs such as WebM would be great, but I’m not holding my breath.
As WeakMap has been implemented from ES6, I’d not be totally shocked if more of that spec is implemented. Especially considering TypeScript prototypes some up and coming features (Update: Set is now also supported). Similarly, MS’ CU-RTC-Web prototypes at least hints something could be implemented. As does the Device Orientation prototype. This would be very nice for mobile and tablets. I guess we’ll find out more at //Build/ in San Francisco.
When?
There is no definitive public release date, but we do know from executive interviews that Windows Blue will be released by the end of the year, and there will be a preview by the end of June. Presumably IE11 will be part of that release.
Thanks to François Remy and Rafael Rivera for digging into the leaked build and releasing some of its secrets. And again to François for further updates on later builds.