Microsoft details Project Spartan’s new rendering engine and why it chose not to adopt WebKit

Microsoft today detailed its new rendering engine designed specifically for Project Spartan, the company’s new browser shipping on all Windows 10 devices (smartphones, tablets, PCs, and so on). The company also confirmed that the new rendering engine will be available in Internet Explorer for Windows 10, which will be primarily used for legacy purposes such as those needed by enterprises.

Microsoft explained the motivation behind building a new rendering engine, why IE just wasn’t cutting it anymore, strategies that didn’t work, what it plans to do this time around, and a few other hints. The company found it had previously focused too much on the “head of the web” (the top 9,000 websites globally that account for roughly 88 percent of traffic) and not enough on the “long tail” (everything else).

[aditude-amp id="flyingcarpet" targeting='{"env":"staging","page_type":"article","post_id":1669064,"post_type":"story","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,cloud,dev,","session":"C"}']

Microsoft identified four major issues in its compatibility approach:

• Legacy vs. modern. Document compatibility modes within Trident were limited and could not be guaranteed. They provided consistent obstacles to fixing long-standing IE-specific behaviors, and fixing long-standing interoperability bugs with other modern browsers could actually break sites coded to IE-specific behavior.
• CV list. Compatibility pass rates were dependent on the presence of the compatibility view list, which allowed Microsoft to “fix” broken sites by forcing them into old document modes that emulated legacy IE behaviors. Unfortunately, this approach requires a lot of testing and maintenance that doesn’t scale well beyond the top sites.
• X-UA-Compatible. Some sites forced an older document mode using the “x-ua-compatible” header, but instead of using it as a temporary stopgap, they used it to keep an old version of the site working in future versions of IE while they developed a proper version for other modern browsers.
• Standards focus. While Microsoft focused on new HTML5 features that comply with web standards, interpretations of the standards document sometimes varied, leading to real-world interoperability gaps between browsers. Ultimately, this led to more bug fixing for developers and more broken sites for customers.

So, Microsoft decided it need to “break from the past” and essentially ditch IE’s Trident rendering engine. While many pushed the company to adopt the open-source rendering engine WebKit, which Apple uses in Safari and a fork of which Google uses in Chrome, the company decided against doing so for two reasons:

First, the Web is built on the principle of multiple independent, yet interoperable implementations of Web standards and we felt it was important to counter movement towards a monoculture on the Web.

Second, given the engineering effort required, we found that we could deliver an interoperability focused engine to customers significantly faster if we started from our own engine (especially if unshackled from legacy compatibility concerns), rather than building up a new browser around an open-source engine.

Microsoft says it is still looking at open source and shared source models “where it makes sense.” What exactly this entails is currently not clear, though the company says it will be sharing more in due time.

Back to the new rendering engine. Because Microsoft decided to split from Trident (also referred as MSHTML.dll), it could keep many of its major investments on the Windows platform as well as remove document modes and other legacy IE behaviors. It also meant the legacy engine could remain largely unchanged for the enterprise world, though it will continue to get security and “other high priority” fixes.

It also means Microsoft can use a new user-agent string to ensure that websites can’t send IE-specific code, and reduce its reliance on the compatibility list. The former resulted in a lower compatibility rate only at first, and the latter aligned head and tail compatibility “much more closely.”

Microsoft also revamped how it finds, tracks, and fixes issues on smaller sites. The company now performs “daily analysis on trillions of URLs crawled in conjunction with Bing to detect patterns that exist in the head of the Web and the tail of the Web.” It then fixes found patterns and “sites just end up working.” This data is augmented by thousands of daily feedback reports from users hitting the “smiley face” icon in the Windows 10 preview.

The best part is that these improvements will continue even after Windows 10 ships:

[aditude-amp id="medium1" targeting='{"env":"staging","page_type":"article","post_id":1669064,"post_type":"story","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,cloud,dev,","session":"C"}']

We don’t see this interoperability effort having an end date – we’ll be continuously checking the data and rolling out improvements to the new rendering engine. For users that upgrade to Windows 10, the engine will be evergreen, meaning that it will be kept current with Windows 10 as a service.

That’s exactly how it should be — the web is constantly evolving, and rendering engines keep up.