"Web developers are our customers," Wilson said at MIX 06, "but there are balance points around that. Although we're committed to making [our standards support] better, we have to balance that along with backward compatibility and along with security. That's not an excuse no to improve; it's just a challenge."
When IE8 came out in early 2009 it, it was clearly an attempt to balance those demands. It was faster and far more stable than IE7, and it had handy tools like Web slices and accelerators for grabbing updated content from Web pages and add-ons that were simpler and less insecure than ActiveX. It also had better support for some of the standards that made up HTML5 at the time, especially for CSS2, and Microsoft changed the behavior of the DOM to match that of other browsers.
But IE8 had compatibility mode for developers who wanted the older IE behavior. It wasn't exactly the same, and developers still had work to do, but it's what a lot of enterprise developers jumped on to keep their old sites working -- and stayed on.
Meanwhile, Firefox had gained significant market share, Apple had launched the iPhone 3G, and Google had come out with Chrome. Both Apple and Google used the WebKit browser engine. Web developers were keen to build sites designed to for WebKit and iPhone.
The problem was they sometimes hard-coded in references to browser-specific implementation of unfinished standards (tagged with browser prefixes) without always including the code for the standard itself. Thus, even when IE supported a standard, it wouldn't be able to run those pages correctly. That is why you started hearing the phrase "same markup" from Microsoft. If developers would only give IE9 the same HTML, CSS, and JavaScript code they gave other browsers, the IE team begged, IE9 would be able to cope with it.
Hachamovitch said it so often that he began to joke about the "same-markup drinking game." But the problem was bad enough that in early 2012 Daniel Glazman, co-chair of the W3C CSS working group, wrote an official call for action naming "WebKit the over-dominant browser on the mobile Web," pleading with developers to stop making "works-only-in-WebKit" sites, and requesting Apple and Google offer their WebKit-only CSS properties to the W3C so that they could become standards. Otherwise, other browsers would have "no other option" than to use WebKit prefixes, even if they didn't use the WebKit rendering engine, and "turning a single implementation into a worldwide monopoly."
It would be IE6 all over again, only worse. In fact, by IE11, IE had indeed started telling websites it was "like Gecko" in an effort to get that same markup, and on Windows Phone IE supports those WebKit prefixes.
Reinvigorating Internet Explorer: From IE9 to IE11
In 2009 and 2010, the IE team was getting ever more involved with Web standards, from giving feedback on WHATWG's HTML5 draft specification to joining the SVG working group.
Ironically although IE had never implemented SVG, Microsoft was partly responsible for its creation. When Microsoft got together with Macromedia, Visio, and Canon in 1998 to suggest a VML specification for vector graphics on the Web that overlapped with Adobe's PGML plans, the W3C told all the companies to work together; those discussions became the basis of the original 2001 SVG specification, and Microsoft worked with Adobe to create the original SVG browser plug-in.
It was clear that Microsoft was getting back in the game. "On August 7, 2009, [IE program manager] Adrian Bateman did what no man or woman had ever done before: He gave substantive feedback on the current editor's draft of HTML5 on behalf of Microsoft. His feedback was detailed and well-reasoned, and it spawned much discussion," Google's Mark Pilgrim commented at the time. "After five years of virtual silence, nobody wants to miss the opportunity to engage with a representative of the world's still-dominant browser."
The plans for IIE9 were far more ambitious than for IE7 and IE8, and Microsoft didn't merely want to catch up. Hachamovitch and Sinofsky went recruiting again and picked up heavy hitters on the team. In 2008 they'd already snapped up Jason Weber, one of Gates' technical assistants (think less fetching coffee and more consulting on Microsoft company strategy) to work on performance. Rob Mauceri (who briefly ran IE after Hachamovitch moved on run a cross-Microsoft data science team) had come to Microsoft when it bought Vermeer, creator of the HTML authoring tool that became FrontPage; he moved from the Office team to "reinvigorate" IE.
And Microsoft had Ted Johnson, who had created the Windows version of the classic desktop publishing tool Aldus PageMaker and later founded Visio. He came to Microsoft when it bought Visio in 1999 (not long after the two companies cooperated on VML), left to build a cloud service, and returned in late 2008 to work on IE9, to get SVG right this time -- and in less than nine months, Microsoft built SVG support into IE.
Although IE9 didn't ship as part of Windows 7, Microsoft wanted to take advantage of Windows and the PC hardware it was running on. As then-Windows chief Sinofsky put it at the time:
... the world for a time went down this path where the browser was a little program you just ran on top of the OS. It was this cool thing that didn't care about the device hardware or the OS; it was agnostic to all that. That can work for a period of time, but underneath the hardware has been changing rapidly and eventually the hardware capabilities transcend that.
If you want location or a screen that rotates as you turn a tablet or to take advantage of the GPU for performance, he pointed out, "browsers need to know what's going on on the hardware to move forward; the whole way you architect and write a browser has to change." That didn't apply to IE only:
No browser vendor needs us to tell them that if you want to do SVG you're going to need to use the GPU. We're all going to do just-in-time compilation; if you want to do that you have to think about how to do threading and multiprocessing, and the OS can help do those things well. We think using APIs in Windows is a good thing -- and we think that writing a browser that uses them is the only way to really do a great job on HTML5.
That connection to the hardware was one reason IE9 didn't run on Windows XP (along with security issues and the fact XP was already nearly 10 years old); XP didn't have a version of DirectX that would give you the hardware acceleration that IE uses for everything from zooming to rendering fonts to playing videos to drawing SVG. "It's about running with the whole power of the PC," Hachamovitch said in 2010. The message was the same when IE11 came out in 2013: "With Windows 8.1 and IE11, the browser is no longer a commodity -- it's a way to differentiate the device and the operating systems."
Chrome might carry on support XP, but that wasn't worth doing, Hachamovitch claimed: "Using compatibility layers to run cross-platform in nonnative ways makes browser development easier; [but] it doesn't always make a better browser or the best experience of the Web."
The other factor behind IE9's improved performance was the new Chakra JavaScript engine from Weber's team (one of the last projects Wilson was involved with before moving on to Google). Chakra doesn't only run the JavaScript in a Web page; it uses a separate core on multicore processors (including on ARM systems like Surface RT and Windows Phone 8.1) to compile it in advance.
As a result, IE9 quickly caught up to the performance of Chrome and Firefox, at least on JavaScript tests (and slowdowns in other areas were often caused by ActiveX controls and plug-ins rather than the browser). But the issue of standards and tests wasn't settled.
IE near the end: Common standards, stable standards
With IE9, Microsoft wasn't simply following the standards; it was picking through them with a fine-toothed comb, suggesting improvements (SVG hadn't been significantly updated since the 2001 specification and the code that IBM wrote in 2003 and donated to the open source browsers like Firefox) and writing thousands of tests to check the IE implementations it donated to the W3C.
"We love HTML5 so much [that] we want it to actually work, and in IE9 it will," Hachamovitch said at the MIX 10 conference. "And so in IE9, we will do for the rest of the Web platform what we did with CSS 2.1 in IE8." IE's head of testing, Kris Krueger, didn't only work with the W3C on handing over the tests; he became the head of the W3C HTML5 testing task force (and Paul Cotton became co-chair of the HTML working group).
For IE9, the team focused on commonly used standards and standards that were stable enough to implement without worrying that they'd be out of date a month after the browser shipped: HTML5 video, audio and canvas tags, some of CSS3, ECMAScript5 (including the strict subset of JavaScript), geolocation, and the Web Open Font Format. In typically thorough Microsoft fashion, it scanned 7,000 websites to find which Web standards developers were actually using -- not only which showed up in popular tests.
Even as IE was improving its score on the ACID test, Hachamovitch wasn't afraid to critique it.
The ACID 3 test is a proxy that many people use for standards compliance. ACID has 100 tests of features, some of which were under construction when it was written, some of which went back into construction afterward. You can have a score of 100 on ACID and completely mess up these borders I'd want to use on my page. ... If I can score 100 and the same markup fails, maybe there's a problem in the test?
Even in WebKit browsers, he pointed out, not every page looked the same. "There are great examples of where the same HTML markup does radically, painfully different things -- not just between IE and other browsers but between other browsers and even between different versions of WebKit," Hachamovitch said.
It wasn't IE6 versus the Web, Hachamovitch said: "We heard the talk about this IE6 problem, and we're calling out that there's this problem with every browser. It's not like there is this happy bubble world where everything interoperates and IE is over here."
In June 2010, neither IE nor Firefox could get a full score on the ACID 3 test because it looked for SVG font support, though that wasn't widely used on the Web (and the SVG working group was prepping significant changes to the SVG spec). Hickson was concerned about simply removing the test in case it looked like he was "trying to make it easy for Firefox," but in September 2011, he excised several "antiquated and unusual" sections of ACID 3. As a result, IE joined the other browsers in getting a perfect score.
Some standards Microsoft was slow to adopt. For example, IE didn't add WebGL support until IE11 -- by which time the WebGL standard had changed to fix the security issues Microsoft had been concerned with. Microsoft had also added WebGL checking to the SmartScreen phishing and malware scanner that was now blocking almost all malicious URLs and malware in tests, and the new version of DirectX could back off instead of crashing if malicious WebGL tried to overwhelm the GPU.
Similarly, Microsoft waited out the Webworkers spec until it stopped changing -- and breaking sites built on it. Firefox and Opera had WebSocket support long before IE10 added it, but they had to remove it in 2010 because of a security flaw. It was only in IE11 that Microsoft's adopted Google's SPDY protocol (after the HTTP working group had started incorporating it into HTTP2).
IE10 -- announced less than a month after IE9 shipped in March 2011 -- added more CSS3 and HTML5 standards, as well as integrating the Flash plug-in and bringing in a touch-friendly, full-screen browser interface for Windows 8 and Windows RT.
Other standards Microsoft started work on while they were still controversial. In addition to supporting third-party tracking protection lists, IE9 was the first browser to turn on the still-undefined Do Not Track header. And the media extensions for streaming protected video content it supported in IE11 had generated furious debate inside the W3C.
"There are three parts," Hachamovitch explained at the time. "There is the Web crypto, so that Netflix can go, 'I want to make sure you really are generating a key for me so that we can do the handshake.' No one seems to mind the Web crypto one, no one seems to mind the Web streaming one. And the last one has a lot more to do with somebody's business reality. I don't know if I believe in rights management philosophically; I know Netflix has contractual agreements and I have a choice: I can enable it in the browser or I can condemn everyone to have to go get an app or a plug-in."
Microsoft also started proposing its own standards. It offered the W3C the Tracking Protection List specification. The Navigation Timing spec from IE9 was quickly adopted by other browsers, but despite encouraging comments they've been slower to pick up Microsoft's Pointer Events suggestion for handling touch, mouse, pen, and other ways of interacting with a device. One likely reason for the resistance: Pointer Events works differently from the touch support Apple created for WebKit. However, Firefox and Chrome are adding support for Pointer Events now, after much debate, but there's no sign of it in Safari.