This article is part of a web development series from Microsoft. Thank you for supporting the partners who make SitePoint possible.
Over the last year the Microsoft Edge team has been hard at work on a new browser engine that will be better than ever at correctly, quickly, and reliably rendering the Web. As a user, your favorite websites will just work, and as a web developer, you will find that Microsoft Edge should just work like other browsers, making it easier than ever to create a site that works everywhere.
We’ve implemented over 45 new standards — more than we’ve ever done in one release. We also made thousands of large and small improvements to make Edge more interoperable with other browsers to ensure that you get a more seamless web development experience.
Aligning browsers, content and specifications
The Web is built on the principle of multiple independent, interoperable implementations of web standards, and we feel it is important do our part in moving the Web forward. True interoperability means that all web content, browsers, and specifications align on the same well-defined behavior.
As we’re evolving our engine to be more interoperable with Blink and WebKit, we’ve spent considerable time working with all browser vendors to fix interoperability issues in browsers and specifications.
As detailed before, we forked our old MSHTML (Trident) engine, which tried to balance both backwards compatibility and modern web interoperability, into a new ‘interoperability-first’ engine called Microsoft EdgeHTML. At the start of this journey, we had to make several changes:
An ever-growing pack of lies
One of the most impactful changes to improve Microsoft Edge was also the simplest – changing the user agent string that identifies the browser to web servers.
Even today, a large number of web servers still sniff the user agent string to give browsers different content. We fixed a huge number of issues by just changing the user agent string and getting more modern content that worked without any issues in our existing IE11 engine.
All user agents strings contain more information about other browsers than the actual browser you are using – not just tokens, but also ‘meaningful’ version numbers.
Internet Explorer 11’s UA string
Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko
Microsoft Edge UA string:
Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/42.0.2311.135 Safari/537.36 Edge/12.10136
The userAgent property has been aptly described as "an ever-growing pack of lies" by Patrick H. Lauke in W3C discussions. ("or rather, a balancing act of adding enough legacy keywords that won’t immediately have old UA-sniffing code falling over, while still trying to convey a little bit of actually useful and accurate information.")
We recommend that web developers avoid UA sniffing as much as possible; modern web platform features are nearly all detectable in easy ways. Over the past year, we’ve seen some UA-sniffing sites that have been updated to detect Microsoft Edge… only to provide it with a legacy IE11 code path. This is not the best approach, as Microsoft Edge matches ‘WebKit’ behaviors, not IE11 behaviors (any Edge-WebKit differences are bugs that we’re interested in fixing). In our experience Microsoft Edge runs best on the ‘WebKit’ code paths in these sites. Also, with the internet becoming available on a wider variety of devices, please assume unknown browsers are good – please don’t limit your site to working only on a small set of current known browsers. If you do this, your site will almost certainly break in the future.
Past problems
To further ensure that websites don’t detect our new engine as Internet Explorer, we also spent a lot of time removing legacy IE-isms (No more ActiveX!).
In an ideal world, web developers would write interoperable content that contains prefixed and unprefixed CSS – unfortunately, this is not the case. In 2014, we had to add support for WebKit-prefixed CSS to render a very large number of modern (mobile) sites, after which we observed an improvement on more than 40% of mobile web sites. Rendering a usable mobile Web now depends on your browser supporting WebKit CSS prefixes; an approach that even Firefox is using.
Accepting WebKit CSS is trickier than just parsing static CSS; we also need to list –webkit– properties first when they are enumerated, as a significant number of sites prepare prefixed CSS using the first vendor prefix they discover.
Continue reading %Building a More Interoperable Web with Microsoft Edge%
by Frank Olivier via SitePoint
