Internet Explorer 11 review, part 1

In this review of Internet Explorer 11, I’m going to attempt to ascertain if it can actually be considered a modern browser.

There has been much written about IE since Microsoft allowed to to stagnate with IE6. There have been a number of jokes written about IE; you probably reconigse them, as they are hardly original and get repeated ad nauseam. There is the one about how slow IE is, then how unpopular it is, and then the one about downloading [insert the favourite browser de jour here]. Then there is the revisionism about IE6. Yes, it actually was a good, and popular browser. when it was released.

But, do the popular perceptions about IE still hold up today, or are they as outdated as those about memory management in Firefox, or that Opera (who boasts a quarter of a billion users on mobile alone) has no users? Read on to find out.

First, an important disclaimer. While I do not work for Microsoft, I am part of the IE userAgents community and the company I work for is a vendor for Microsoft. However, Microsoft did not ask me to write this post, nor have they seen it or suggested any content. In fact I’ve just finished it a few seconds ago. I have also been involved in various roles with Opera and WebKit.

Ever since IE10 was getting ready to be released, I’d tell anyone that would listen that “hey IE9 is pretty crappy, but IE10 is looking to be a pretty good browser. I suspect by the time IE11 comes out, it will have caught up with the other browsers.” So, did that actually happen? This post, and subsequent ones in the series will attempt to find that out.

First we have to define what a modern browser actually is. I’d define that in various ways. As a web developer, I care about web platform capabilities, especially as they pertain to open web standards. A modern web browser has to be able to support what web developers are building today, and what they may want to develop in the near future. A modern browser needs to be performant and keep the user secure. To achieve this it probably needs some form of modern architecture that takes advantage of today’s hardware capabilities. I’d also argue it needs to offer a well rounded developer story, such as developer tools and the ability to be deployed quickly, without having to wait years for users to upgrade to the latest version. Above all, it needs to keep pace with the competition, as if it is way behind the other browsers, it is holding the web back. We saw this with earlier version of IE as they attempted to catch up from a 5 year head start they gave to everyone else.

There is too much to cover in one post, so I’m breaking this review down into multiple parts. Even I don’t know what the result will look like in the end. For this first part, I will look into the elephant in the room; IE’s release schedule and update strategy. I will also briefly look into the story around use of prefixes and standardisation of new features. Lastly I will take a shallow look at web standards support as measured by popular test sites. As these sites have major gotchas, in subsequent posts, I will look into greater detail for each of the major areas: HTML, CSS, JavaScript, and web platform APIs. This post will see where IE11 stands with the features those test sites choose to measure, while the deep dive will attempt to look at all the features as a whole, including those missing from the tests.

Release schedule

It doesn’t matter how good or modern a browser is, if it is not in the hands of the user. I call this the elephant in the room for IE as it is an area where Internet Explorer receives a great deal of–mostly warranted–criticism. The biggest issue, of course, was that hulking big break between IE6 and IE7. At approximately 5 years and 2 months, this period was the dark ages of the Web. The gap between releases has come down since, but they are notably less frequent than other modern browsers, but one.

There are now essentially two release models for browsers. Chrome and Firefox have moved to a rapid release cycle, releasing approximately every six week. IE and Safari are generally tied to OS releases, so are at the mercy of their cycles. Opera was somewhere in the middle with a couple of releases a year, but have moved to the Chrome model now that they’ve switched to Blink.

So how often is IE released, and how does it compare to Safari? Let’s look:

IE release history

Although IE11 was released a year after IE10, each release has been coming progressively faster. As IE10 for Windows 7 was actually delayed by 4 months, it was released just 8 months before IE11 for Windows 7.

Safari release history

Now let’s compare how Safari stacks up:

As you can see, Safari originally had long release cycles (as did everyone at the time), had a period of rapid (for the era) releases, and have settled into a release per OS version cycle. This is around one release per year, but as OS X has (purportedly) been delayed due to allocating more resources to iOS, this has slipped somewhat, especially with the latest version.

If you compare with IE, there were two Safari releases per IE release between IE8 and IE10. IE11 on the other hand was released before Safari 7, and thus technically there were no Safari releases between IE10 and 11, but in reality both are on similar yearly release schedules, with IE getting slightly faster. It will be interesting to see if IE continues to reduce the gap between releases or stick to the once a year releases. Other apps built into Windows 8 get updated out of band, but they are not as deeply tied into the OS as IE.

While I’d prefer more regular updates than once a year (perhaps quarterly or every half year would be nice), it is clear that IE is keeping pace with its most similar competitor, and the improvements are encouraging. If IE can’t be considered a modern browser due to it’s release schedule, then the only major desktop WebKit browser on the market can’t be considered modern either.

Update strategy: Evergreen browsers

While regular updates are nice, they don’t mean anything if old versions stick around (Hello IE8!) Getting users onto the latest version is critical. Firefox and Chrome have this down to a T; they really have to, as with releases every 9 weeks, if it took longer to update they’d not have transitioned before the next release comes out.

Browsers that auto-update in this manor have become known as evergreen browsers. Users are always on a pine fresh browser, and all is good with the world (never mind that pines and furs shed needles.) IE versions are presumably deciduous browsers. Grand old oak trees that stand stubbornly proud for many years, with armies of squirrels pelting web developers with acorns.

So which is IE11? The good news is that since IE9, Internet Explorer has included auto-update functionality. In theory then, IE9 and above are evergreen browsers. There are however some complications. While IE9 does auto-update, IE10 was never made available for Windows Vista. As such, IE10 has surpassed IE9 in any marketshare metric you care to look at, but it still has a bunch of users: around 6-7 percent using StatCounter, Akamai and Clicky stats, and 9.5% on NetApps (which is always the outlier due to the way it adjusts its data.)

While IE10 drops Vista support, IE11 is available for the same platforms as IE10. Well, not exactly; it is available for Windows 8.1 instead of 8, but it is a free update that will be pushed out to all Windows 8 users. In theory, while a bunch of IE9 users will remain, IE10 should disappear completely, except for those evil sysadmins and enterprise developers (as Bruce puts it in his previously linked video) that may block the update for their users.

While that is the theory, how is it working out in practice? It is too early to say, but the signs are promising. Using StatCounter stats, IE8 took 9 months to reach the same marketshare as IE7, while IE9 took 1 year to reach IE8. IE10 on the other hand took 29 weeks to overtake IE9, but only 11 weeks from the release of IE10 for Windows 7. It also took 11 weeks from the Windows 7 release using Akamai stats and 13 using Clicky Stats. As IE11 for Windows 7 came out only 3 weeks after the 8.1 version, we should see this time drop dramatically. [Edit: less than a week after thi s post was publish, IE11 surpassed IE10 on both StatCounter and Clicky. The table below has been updated with this week’s data.] But even if we just take the Windows 7 releases into account, the uptake speed is currently faster for IE11. In the table below, I take the market share on each day exactly a week after the previous, starting one week after the release date on Windows 7.

Even though IE11 had been on the market for less time when the Windows 7 version was released, and thus starts with a lower market share, it is around 6 weeks ahead of what IE10 was on Clicky, and around 2–4 weeks ahead on StatCounter. It has already surpassed IE10’s market share on both services. I’ve not included Akamai in the table above as it does not yet detect IE11. NetApps on the other hand doesn’t support daily or weekly stats without a paid upgrade.

If you look at the trend graph for both Clicky and StatCounter you can clearly see IE11 growing at the expense of IE10. While Akamai currently doesn’t detect IE11, you can see IE10 starting to rapidly fall away.

As an aside, IE7 is way more popular on Akamai than StatCounter and Clicky. This is almost certainly because Akamai detects IE browsers in compatibility mode as IE7. As Akamai is used by many of the top traffic sites, and thus more likely to be added to the compatibility list, I suspect this is a large percentage of these users. They will be fixing this issue shortly.

Although IE adoption time is dropping between releases, it is clearly slower than Chrome and Firefox. Part of this is likely due to the type of users IE has versus those browsers (especially enterprise users), and the release schedule not mandating such a rapid adoption rate. It also seems that Microsoft is more conservative with pulling the trigger on the updates. You can clearly see stages in IE adoption where the current version of IE jumps then plateaus for a while. This suggests that the users are updated in stages. Probably after minor releases are ready and bugs have been ironed out.

With Safari, you can clearly see with Clicky stats that there is a dramatic uptake right out of the gate for Safari 7. This is likely due to OS X Maverics being free for all users of fairly recent versions of OS X, and Apple being far more aggressive pushing that update out. On my OS X machine the update showed right away, while I had to go digging for the Windows 8.1 release. You can see however that the uptake has started to plateau, and that the uptake of 6.1 (essentially Safari 7 for the previous version of OS X) is slower. Safari also has the same issue as old version of IE, with Safari 5 and 5.1 still hanging around. Indeed, 5.1 is currently the most popular version of Safari. I suspect Apple’s policy of giving away the OS for free will lead to modern versions dying off quickly, but it remains to be seen if 5 and 5.1 continue to overstay their welcome.

For IE adoption going forward, the key issue is when and if they drop support for older versions of Windows. We can see this creates beach heads where certain users are stuck on a version of IE. We see this with IE8 and XP, and perhaps IE9 and Vista (which is fortunately less popular and likely to have a fraction of the impact.) If Microsoft drop support for Windows 7 we could have a catastrophe of IE8 proportions. I really don’t see that coming though. With Windows 7 as popular as it is, Microsoft would be mad to drop it any time soon. Windows 7 is actually a pretty good operating system, so there is little benefit to dropping it right now, while supporting XP would take substantial resources. I’ve heard talk of Microsoft only supporting the current OS and current OS - 1, but that is just not how things have worked in the past. Ignoring server versions, IE8 was available for Windows 7, Vista, and XP, while IE6 was on XP, ME, 2000, 98, NT4, and 95.

In conclusion, this is clearly an area where Microsoft could do better, but things look like they’re moving in the right direction. IE8 will haunt us for a while, but the mistake shouldn’t be repeated with modern versions of IE, as long as they continue to keep Windows 7 along for the ride. I’d like to see Microsoft be as aggressive as Apple with pulling the trigger on the auto-updates. We’ll have to wait to see if this happens, as we’re only a month into IE11 for Windows 7.

Prefixes and standardisation

Prefix strategy

Prefixes are a pain for everyone, causing compatibility issues for users and browser vendors, and maintenance issues for developers. It is clear something has to be done to fix the problem. The Solution Google and Mozilla have come up with is to not add prefixes for new features and include the feature behind a runtime flag, disabled by default. The thought is that if the features are not exposed to the web, the standardisation process will move faster as the browser vendors will want to include the feature, and the development to update the feature to match the spec will happen faster.

This feature behind a flag solution has been adopted by Firefox, Opera, and Chrome. Safari meanwhile looks like it will keep polluting the Web with -webkit- prefixes, although there is no definitive official statement.

As for IE, mum is the word so far. If Microsoft don’t adopt this method, we’ve only really lost the -moz- and -o- prefixes.

So far we have been fortunate that there are not that many -ms- prefixes out there. Microsoft’s strategy has been more conservative in that they generally implement mature specs, such as how they were the first browser to fully support CSS2.1. As they were playing catch up from their long siesta, many of the CSS3 specs were mature enough to implement without a prefix. That is no longer the case now.

Newly proposed IE11 features such as ime-align do use a prefix however.

My main worry is that with less regular updates, IE and Safari will be less likely to disable new features they’ve added, as it will take a year–rather than nine week intervals–before they get the chance to enable them. I can’t say either way which way IE will go, so this is one for the future.

Standardisation

While standardisation of features doesn’t really relate to if a browser is modern or not, it is indicative of modern thinking by the browser vendor, and their willingness to play well with others. I will also only include features on the standards track in the deep dive into standards support in future articles.

So, how is Microsoft doing in this regard?

One of the headline features of IE10 was touch browsing. Instead of the (potentially patent encumbered) Apple touch events model, Microsoft made their own Pointer Events model. This was submitted to the W3C, and within a year it has become a Candidate Recommendation. IE11 was updated to the latest spec, and the prefixes were removed. So far, so good.

Also related to touch, IE10 added its own proprietary CSS properties for scrolling and zooming with touch. The scrolling properties were updated in IE11 and added to a new Scrolling Snap Points spec. I’m not sure what is happening with the zoom properties.

In IE11 almost all of the new features seem to be based off existing standards or proposals. They went with WebGL and Google’s SPDY, rather than inventing their own incompatible alternatives (WebDirectX anyone?) One of the new headline features is the ability to play “premium video content.” Microsoft is an editor on many of the various specs that enable this, including TML Simple Delivery Profile for Closed Captions, EME, MSE, etc.

One area where IE11 adds new prefixed features is for working with IMEs (Input Method Editors, as often used for CJK (Chinese, Japanese, Korean) languages.) These new properties and methods have been submitted to the W3C as the Input Method Editor API. At the time of writing this is still an Unoffical Draft.

In conclusion, while the prefix situation remains unclear, Microsoft look like they are well and truly on the standards track with IE11. It is encouraging that there was no major new feature added that doesn’t have an existing spec or a proposal submitted.

Standards support

Standards support is the area where most developers would judge if a browser is modern or not. If you read Tweets, you’d get the impression that IE is way behind the competition in this regard. But does the perception meet reality?

To answer that question fairly, we’d have to look across the various specs and see how each browser stack up. I plan to do that, at least for the major specifications, but for the first part of this review I’m going to look at the commonly used standards support tests to give a first impression. I’ll also cover what they actually test, and any drawbacks they may have.

HTML5Test

Probably the most commonly used test is the HTML5Test. This focuses on HTML5 (obviously), but also includes a bunch of things not in the spec. It does not cover CSS (except one feature), JavaScript, DOM, SVG (beyond testing if it works in HTML documents), or various other specs. As is common with these kinds of test, it only covers features that were new when the test was first made, and those that were released since then. As such it also doesn’t cover features that already existed in HTML4 and below.

The test gives a score for each feature supported. The score differs between features, so it depends on what value the author gives it. As with other tests of this type, it does not test how well a feature is supported.

As many of the features tested are relatively new, the score is more relevant the newer the browser. For older browsers, many of features may not even have existed when it was released. As such you shouldn’t give much stock in how much better or worse IE8 is verses it’s competition at the time.

What HTML5Test does tell us is how well browsers support some HTML5 and cherry picked APIs, based on the weight the author gives those features.

So how do IE versions stack up to other browsers of similar vintage?

Internet Explorer 8 vintage browsers

Note: Chrome 2 was actually the closest release to IE8, but it is not listed on the HTML5Test site.

Here you can see that Gecko and WebKit browsers are dominating IE, and to a lesser extent Opera. In the context of this time frame, you have to remember that many of the features tested did not exist yet. The IE8 release also focused on CSS2.1, which is not tested here at all.

Internet Explorer 9 vintage browsers

Here we can see that each of the browsers increased the gap over IE9. Firefox moved from first place to second last, behind Opera. By this time Chrome has shown a dominance in this test that it has never relinquished to this day.

Internet Explorer 10 vintage browsers

It is with IE 10 that I feel Microsoft was done with catching up with the foundational features it lacked (DOM, CSS2.1, etc) and was ready to add more modern feature. Did that prove to be the case?

While Opera 12.1 (the last ever Opera Presto version, RIP) surpassed Safari,and Chrome remained on a tear, IE10 got within two digits of all browsers except Chrome. Similar gains with IE11 would move it to 2nd position.

Internet Explorer 11 vintage browsers

This was a mixed bag for IE11. It is now only 21 points from Safari and closed the gap slightly with Chrome, but lost ground to Firefox and Opera. The latter benefiting from the switch to Blink.

When IE10 came out, I expected IE11 would at least catch up to one of the other browsers. That didn’t happen, but that can perhaps be attributed to having a shorter release cycle than the previous version.

Overall, despite still being in last position, IE is within spitting distance of Safari, and not out of sight of Firefox. There is certainly a case to be made that it is a modern browser here.

HTML features supported by all browsers except IE11 include the main, meter and output elements, and the reversed, ping, elements attributes, and the control and form property, and the on invalid event. APIs not supported include the Web Audio API, Server Sent Events, and CSP 1. CSS (!) not supported includes Blending Modes.

CSS3Test

The CSS3Test covers new features in CSS level 3 specs and some new CSS level 1 specs. It does not cover features that existed in CSS2.1 (so IE8 having better support than many browsers is not reflected). It also does not include every CSS spec, or CSS Level 4 property/values (keeping up with everything is time consuming, especially when these tests are usually hobby projects.) The test checks for the existence of features rather than if they are actually supported. As is mentioned in the test itself, browsers can claim support, without actually doing anything more than parse it. Some WebKit/Blink based browsers may have an inflated score because of this.

I believe the way scoring works here is that every test is worth an equal score. So a spec with a lot of properties or values will be given a lot more points than a spec that may be as complex or more so, but with few properties or values. The test does not distinguish between supporting a property with or without prefix, however, if a property or value was renamed, the older syntax will not be picked up. IE10 in particular suffers from this with CSS Grids and Flexbox.

With all that in mind, on to the results:

Internet Explorer 8 vintage browsers

IE8 does not run on CSS3Test, so I couldn’t get a score here. Chrome 2 is no longer available on BrowserStack so I could not include that either. I used Firefox 3.6 instead of 3.5 as that is no longer available on BrowserStack either. So, all in all, you can’t tell much from this round of tests.

Internet Explorer 9 vintage browsers

As with Chrome 2, Chrome 10 is not available on BrowserStack. Firefox, Safari, and Opera are all within 4% of each other, with Opera showing the largest growth. IE9 was well off the pace.

Internet Explorer 10 vintage browsers

With the HTML5Test, this is where things got interesting. Will it perform as admirably on the CSS3Test?

In this round IE10 matched the scores of Safari and Firefox, and is only 2 percent behind Opera. If CSS Grids and Flexbox didn’t change syntax, Safari didn’t claim to support background-repeat which it doesn’t, and specs like Exclusions, @viewport, Scrolling Snap Points, or the hyphen properties from CSS Text Level 4 were included, IE10 would have pulled ahead of those browsers, and perhaps Opera.

This was the first time Chrome has been included, and it has a healthy, but not insurmountable 6 percentage point lead.

Internet Explorer 11 vintage browsers

The situation is even more tightly packed in this round, with Safari and Opera joint leaders, but only 3% ahead of IE and Firefox. Chrome is 1% behind the leaders due to an accident of timing; the latest betas are up to 61% too.

This particular release wasn’t particularly interesting in terms of CSS for IE11, but switching to the latest Flexbox syntax gained it a bunch of points that would have otherwise been given to IE10.

The next release should be interesting now that Google and Apple have split and no longer benefit from each others work (unless the work is ported.)

Although the test (like the others) doesn’t show a complete picture, it is clear from this test that IE11 is a modern browser in terms of CSS support.

The CSS properties supported by all browsers except IE11 include outline-offset, resize, tab-size (only partially supported by other browsers), and text-align (also partial support by others). The :default, in-range, :out-of-range, :read-only, and :read-write pseudo classes, and the vmax value are also supported by all browsers except IE11.

The main missing feature in my opinion is the preserve-3d value of the transform-style property. The others, while nice, are not critical.

Can I Use…

While the other tests focus on one area, such as HTML5 or CSS3, the Can I Use… site includes a hodge podge of different features and technologies. As its focus is on telling the user what features are supported, it mainly includes relatively newer features, or older features that were not in IE.

Drawbacks of other sites also hold, such as not having complete coverage of each technology. Unlike the other tests, it is not automated, so the author checks if each feature is actually supported. For some things this can be subjective, such as IE having a partial rating for the number input type due to not having number spinner UI, even though there is explicitly no requirement for this in the spec (specs do no mandate UI choices), or how Firefox, Safari, and IE are listed as supporting hyphenation due to supporting the hyphens property, even though there are a number of other hyphen properties which they don’t all support.

Most of the new IE11 features that are not well supported in other browsers are not included on Can I Use…, including Screen Orientation API (IE and Firefox), Web Crypto, SDP, EME, MSE, Scrolling Snap Points, etc.

With that being said, let’s look at the results. I’ve broken down the scores to features that are Recommendations, Proposed and Candidate Recommendations, and Working Drafts, and the total of those combined. I’ve excluded features that are unofficial (not in a specification) or “other”, which includes a bunch of things that are not required by specs, such as a number of image and video formats. Unfortunatly the latter also excludes WebGL and Typed Arrays, but these are supported in IE11.

Internet Explorer 8 vintage browsers

Chrome 2 is not listed on Can I Use… so isn’t included here. In this test IE8 is a long way behind the other browsers; under half the score of Firefox and Safari.

Internet Explorer 9 vintage browsers

Internet Explorer 10 vintage browsers

Here was can see–similar to other tests–that IE10 made big gains. It caught up to Opera and is within 5% of Safari and Firefox.

Internet Explorer 11 vintage browsers

We see mixed results from IE in this round. IE11 edges slightly closer to Chrome, but falls behind Opera (benefiting from the switch to Blink), Safari and Firefox. As mentioned previously, much of what was added to IE11 is not included in Can I Use… so the progress made over the last version doesn’t look as impressive as it could.

Note: The scores on Can I Use… changed after I published this post. The data above now includes the updated figures. Previously IE11 also gained on Safari, but the updated figures generally benefited recent WebKit/Blink browsers (+1% for Opera and +2% for Safari), and reduced IE 11’s score by 1%.

So what does IE11 lack that puts it behind the other browsers? For Recommendation specs it is SVG Fonts (also not in Firefox) and SMIL (rated partial for Safari) that put it behind the other browsers. In my opinion both are not critical. SMIL has largely been ignored in favour of JS animation and is being replaced by CSS Animations, and SVG fonts have largely only been used for iOS due to lack of support for TrueType fonts in earlier versions.

The only features tracked by Can I Use… that are fully supported by all other browsers than IE are the CSS resize property, Server-Sent events and CSS Intrinsic & Extrinsic Sizing. The Web Audio API, which is listed as partially supported for all other browsers is also not supported. These would be nice to have (especially Web Audio API) but none of them are a WebGL sized hole in IE’s support story.

Kangax’s ECMAScript compatibility tables

To measure ECMAScript support, there is no ES6Test or the like. Instead I looked at Kangax’s ES5 and ES6 compatibility tables. As these are not a tests, there is no scoring. Instead I counted up all the supported features and awarded 1 point for each.

As with other tests, the same caveats about scoring and support apply. There may be features that are not included in the test (especially as ES6 is a moving target), some tests only check for existence rather than actual support, and the scoring I applied makes no attempt to weight based on importance, complexity or so on. It would be easier to rack up points by supporting a bunch of the new Math methods than add something more complex.

Also note that these tables do not include the ECMAScript Internationlization API. This is currently supported by IE11, Opera 15+, and Chrome 24+. It is not available in Safari, and although it has been implemented in Firefox, it hasn’t been enabled in a release build at the time of writing.

With that said, let’s check out the results.

Internet Explorer 8 vintage browsers

As with previous results, I did not have a copy of Chrome 2 to test. Fairly predictably, IE8 was last and Firefox (known for its stella JS support, with Brendan Eich as their CTO) out in front.

Internet Explorer 9 vintage browsers

This one was surprising to me. IE9 actually had the second best support using this measure; only lacking Safe mode from ES5. Firefox again ends up on top, being the first browser to support all the features of ES5. It lost ground on IE, but only because there was no more ES5 to implement, and ES6 wasn’t ready to implement at this stage.

Internet Explorer 10 vintage browsers

In this round all browsers reached full ES5 support. Firefox started to pull away again with its early implementation of ES6 features. All other browsers had very limited support for ES6 features, or none at all in the case of IE.

Internet Explorer 11 vintage browsers

True to form, Firefox races ahead again, while IE11 regains second place.

There is however something important to note. While Firefox adds new JavaScript features without prefixes, not behind a flag like it does with CSS, Chrome (and Opera) does use a flag to enable new features for JavaScript. Enabling those flags changes things somewhat:

With Experimental JavaScript flags

This would put IE11 second last again, only ahead of Safari (and thus WebKit). But it is important to note that out of the box you can not use these features, so this is more theoretical.

While Chrome uses flags to hide and reveal experimental features for JavaScript, Microsoft has instead been building experimental plug-ins on HTML5Labs.com to test prototypes and unstable specs. If we include flags, it is also fair to include these too.

For ES6, Microsoft provides a plug-in for the new Math, String, and Number methods. If we include these, things look different:

With Microsoft JavaScript Extensions plug-in

There are 21 new methods in all, and that is enough to push IE11 10 points above Opera and Chrome with flags enabled. Of course, you also can’t use this in the real world either, and is harder to enable than a flag. I’m actually surprised Microsoft didn’t implement them natively in IE11 now they are starting to support ES6 and they can’t be particularly hard to implement, especially when they have a prototype.

In conclusion, in the real world where plug-ins and flags can not be used, IE is certainly holding its own in second place. The worst case for IE would still put it ahead of Safari/WebKit, and would be further ahead if the Internationalization API was included in the tests. In JavaScript terms, IE11 has to be considered a modern browser. The only feature supported by all browsers except IE11 is Math.imul.

Official ECMAScript test suites

While I haven’t used official test suites so far, JavaScript is particularly suited to automated testing. ECMA makes available test 262 to test ECMAScript 5.1 compliance, and http://test262.ecmascript.org/testcases_intl402.html# to test ECMAScript Internationalization API compliance. For the sake of brevity, and as only the latest browsers support the Internationalization API, I’ll only list scores for IE11 era browsers here. The scores listed are the number of passed tests. Both tests were run using the 2013-06-13 version of the test suites. This was the latest at the time of writing.

It is no surprise considering the previous round of tests that IE11 did strongly here, especially considering we’re now including the ECMAScript Internationalization API. What may be surprising is that it finished in first place over Chrome and Opera, and that Firefox finished last this time, with the most fails in the ES5.1 tests. This picture will change somewhat once Firefox enables its ES Internationalization API support, and ES6 features are included in the test, but for now IE is the champ.

Totals and conclusion

If we put all the results together, Chrome 30 finished on top twice, and all other browsers finished 1st once each. Opera finished 2nd three times, while IE11 and Chrome 30 finished there once. IE11 finished last twice, with Safari 7 and Firefox 25 both finishing last once. There is clearly not a huge amount in it:

The two places where IE11 finished the highest were for the ECMAScript tests, which may be unfair, but there is also a decent amount of cross over between canIUse and the HTML5Test and to a lesser extent the CSS3Test.

While IE11 is last the most amount of times, it is only 3 percentage points behind Safari 7 on the canIUse tests and 21 points behind it on HTML5Test. With the growth in those scores over the last couple of versions, if IE continues its growth, it is not outside the realms of possibility that it will catch up in the next version; at least to Safari, and maybe to others.

It is also important to bear in mind that IE11 added WebGL. This was a huge undertaking to implement this in a year, and presumably took a lot of resources, while only accounting for 20 points on the HTML5Test, and one feature on canIUse (it is also reported as partially supported in Safari, despite being disabled, so not usable by web developers.) Now that elephant in the room has been squashed (or close to it; it isn’t 100% feature complete), we could see more progress in other areas. I’m personally hoping for more CSS support in IE12. When IE decides to implement something it is often able to move quickly; if WebGL was a case in point, we can also look to SVG (not included in any test here in any detail), which only took one release to go from 0% support to large chunks of the spec.

We’ve seen that IE’s release schedule is keeping pace with Safari, and that it’s take up is becoming more rapid. While there is still a big question mark over prefixes, newly invented IE features such as pointer events, scrolling snap points, IME support, and so on are getting proposed for the standards track.

It will be interesting to see how IE fairs when there is a more complete picture of standards support (coming in later blog posts), and how things like performance and accessibility hold up, but with this preliminary data, I think you’d be hard pressed to claim recent versions of IE are not a modern browser, or in touch with its competition.