June 17, 2015 10:00 am

Building a more interoperable Web with Microsoft Edge

Over the past 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 web sites 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.

Preparing for the future

We care very much about web developers getting a consistent feature set across browsers – which is why we spent a lot of time adding the most-requested features like ES6 (highest score!), HTTP/2, responsive images, and Media Capture, as well as older features like XPath and Motion JPEG support. If you’d like to know what if coming up soon in our evergreen browser, see our new Platform Status and change log pages.

Data Data Data

Browser interoperability requires a never-ending series of features and bug fixes; to maximize the impact of our work, we need to use data to aid in prioritizing interoperability work. Our 3+ million Windows 10 Insider users have been sending us reports of site issues; this data has been invaluable in prioritizing fixes.

We also use data from the Bing web crawler to inform our decisions. The crawler sees 33 trillion pages, 44 billion sites, and usage of seven thousand APIs and it helps us see how web sites at large are built, and how our browser changes will impact the Web. Along with our ability to rapidly flight new versions of the browser, we are able to find and fix interoperability issues faster than ever before. A lot of web sites depend on JavaScript libraries and frameworks, so we also submit fixes to libraries to ensure that they work in all browsers.

Sometimes standards don’t describe actual web content

Interoperability is more than just fully implementing a specification to the letter. We’ve also seen numerous cases where the standard doesn’t actually describe what web developers do, and as a result we have to be more liberal in parsing and accepting content – even if it means deviating from the specification.

One simple example is malformed Meta-Refresh elements. Web servers often use meta refresh to redirect browsers to the mobile versions of their sites. Some mobile sites are sending malformed meta refresh tags (missing the "url"= token) which caused IE to enter an infinite loop of redirections.

<meta http-equiv="refresh" content="0;http://foo.com" />

<meta http-equiv="refresh" content="0;url=http://foo.com" />

The solution here was to parse and handle the ‘malformed’ markup — the Web eventually takes a dependency on the behavior of more permissive browsers.

We’ve also seen numerous cases where the specification is (perhaps) overly prescriptive in defining behavior. Sometimes standards are too pedantic; it is easy to see a web developer making a mistake:

For example, pages often use <meta charset="utf8"> to define the character set for a page. "utf-8" is the ‘technically correct’ description. This is an easy ‘mistake’ to make; there are nearly 600k results on GitHub alone in HTML files.

This caused pages to render incorrectly in IE11 – in this case, the pull quotes:

Example of improperly rendered pull quotes

With Microsoft Edge, we are now more permissive in accepting the "utf8" value, resulting in the correct rendering:

Screenshot of pull quote which is now working due to more permissive acceptance of the "utf8" meta charset value.

As another example, the mobile Web depends on your browser downloading font resources without checking the CORS headers and ’embeddable’ flag (as per spec) — we’ve had to change to WebKit behavior in our mobile browsers to make the mobile Web work.

Screenshot showing example of implementing a more interoperable inter-agent string and deviating from the standard for cross-origin fonts improved rendering on hawaiianairlines.com

As we are making changes to be more liberal in accepting content, we are also working to ensure that the specifications match the behavior that web developers are used to.

Sometimes the Web relies on unstandardized behavior

Large parts of a modern web page rely on browser behavior that is not standardized, and web developers have to depend on browser behavior that is not clearly defined. In these cases, we are working to add and fix specifications to ensure that the behavior of web content in all browsers is reliably specified.

Sometimes the Web relies on browser bugs

We’ve seen numerous cases where web developers start to depend on incorrect behavior in one browser, leading to ugly hacks or UA-sniffing to patch the issue. A good example is the scrollTop bug — once (major) sites started to depend on non-interoperable behavior, it became impossible to fix the issue across all browsers without breaking web content. Sometimes the best path forward is to offer alternatives to broken APIs — Chrome, Opera and Microsoft Edge all now support the alternative document.scrollingElement property.

Another example is moving DOM properties to the prototype chain — a very fundamental change in how browsers work that only recently aligned in all browsers — which makes it much easier to reliably program DOM behavior in a web page.

Getting Microsoft Edge ready for the Web

These are just some examples of the thousands of large and small interoperability changes we’ve made to our browser engine. During development, Microsoft Edge has consistently been more interoperable with the broader Web than any previous Microsoft browser. We’ve endeavored to align with other browsers where it is the best thing for the Web, and we’ve worked with other vendors and the standards bodies to fix issues on their side. Our long-term hope is that web content, all browsers, and the specifications align to a single well-defined well-designed behavior.

Every browser vendor cares deeply about creating an interoperable Web. Evolving the Web without breaking it is exceedingly hard — any mistakes are very, very hard to clean up — but an interoperable Web that just works across all browsers and devices is closer than ever. If you see examples where Microsoft Edge is not behaving interoperably with other modern browsers, please let us know @MSEdgeDev on Twitter or by filing a bug on Connect.

Frank Olivier, Principal Program Manager Lead, Microsoft Edge

ed. note – updated on 6/17 to clarify the UTF-8 example and on 6/19 to change ‘installable’ to ’embeddable’.

Updated June 28, 2018 8:00 am

Join the conversation

  1. Great post. While I agree with the overall message and section headings, there are a few incorrect examples you may want to correct to avoid misleading people.

    > We’ve also seen numerous cases where the specification is (perhaps) overly prescriptive in defining behavior. Sometimes standards are too pedantic; it is easy to see a web developer making a mistake:

    The specification actually requires supporting utf8; this is not a web developer mistake. It’s IE that was being overly prescriptive, in a non-standards-compliant way. https://encoding.spec.whatwg.org/#names-and-labels

    > Large parts of a modern web page rely on browser behavior that is not standardized,

    The link describes the “ construct, which is indeed standardized: http://dev.w3.org/csswg/css-device-adapt/

    • The link you posted for the standard, very clearly says “Editor’s Draft”.
      It’s not a standard yet. If it were a standard it would say “Recommendation”

  2. You messed up the quotes in the “correct” way of writing it –
    > For example, is the incorrect way to define the character set for a page. ( is correct)
    No, is correct. Your “correct” way has two different quotes, neither of which is correct.

    What is this “installable” check to which you are referring in the image? I think you confused two topics?

    Also, only Safari supports cross origin fonts without CORS headers, Chrome stopped supporting that several releases ago, perhaps you should reconsider your stance here?

    Regarding “Sometimes standards don’t describe actual web content”, beside implementing the quirky behavior, you should also work towards changing the standards to mention that. New browser developers (yeah, it is a stretch, I know) should not reverse engineer (or read the source code of) other browsers in order to know that they have to add that quirk. Be accomodating.
    (This goes to every vendor, not just you, obviously)

    Generally, it is great to see an interoperable web and I love the fact that you are more open and accommodating that ever before. 🙂
    (Even if you were forced to this situation…)

    Thank you!

    • Thanks Numb – the quotes were an error in copying this to our CMS and have been fixed.

      • The editorial comments are the easiest to act on, I know. But what about my other questions?

        • Regarding the “installable” check – the surrounding text has been updated to clarify the example.

          Regarding working to change the standards – agreed that in a perfect world the actual standard and common web practices should be aligned, and to that end we work very actively with other browser vendors and standards bodies. At the same time, it’s important to our customers that the web sites they care about work out of the box, so it’s important to balance strict adherence to the standard against rendering the web as it actually exists. As Frank states in the post, it’s our ultimate goal that the web should “just work.”

          Regarding new browser developers, we do document all our variations, clarifications, and extensions to final standards: https://msdn.microsoft.com/en-us/library/ff410218(v=vs.85).aspx

    • Some more detail to your CORS header question – We initially disabled CORS checks for all hosts starting with the Windows Phone 8.1 Update, which was carried forward into Microsoft Edge. Recently, we re-enabled CORS checks on desktop after Chrome started following CSS spec. We still skip CORS for fonts on mobile because Safari and older Android browsers still don’t comply with it in order to preserve compatibility with mobile sites.

  3. I don’t know how many thousands of hours were spent on all these changes. Brilliant work. Thank you Edge team!

  4. I’m dreaming with a day where UA is not used anymore other than to offer a link to a proper app Store.

    I have a Windows Phone and in the version 8.1 a lot of sites offer to download apps from Google Play. At least their sites works.

  5. Good job but please start working on a new Development Tool. The current one is horrible, unusable, sluggish, buggy… Also concentrate on performances but the basic ones: DOM manipulation, arrays cycles, object navigation and so on… these are the reasons behind Chrome success.

    • In one side I understand Chrome has more features in Dev tools but in other side I believe IE div tools is way better.

      A lot of coworkers use Chrome but when they try to find something in its div tools they just can’t . I just show them with two clicks in IE dev tools.

  6. i need to know if microsoft edge will support http 2 without encryption (not over TLS ) ?
    and if not then why ?

    • Not aware of the HTTP2 discussion, but Wikipedia mentions Firefox and Chrome don’t plan to support nonencrypted HTTP2.

      I sympathize with the IE team’s various troubles. I myself have been working to remove various IE-specific CSS rules from our site’s code, frustratedly learning the need for different styling was due to exact font width for certain messages (Which, itself indicates internationalization may go badly). However, I also have to admit to being one of the people to write a RegEx for the new Edge User Agent. Why? I don’t believe this is anything at fault with Edge; in fact, this change largely makes sense. But now that it’s inside the WinRT runtime, it doesn’t allow you to connect to a listening port on localhost; even going through Flash. We happened to use this for communication with our plugin, now that Chrome and Firefox have taken a dislike to traditional NPAPI.

      Our need for a plugin derives from having to support both old and new browsers, and a need for real-time video chat. The worst part? I am *wholely aware* of WebRTC, but it’s just still not there yet; Microsoft’s proposed alternative isn’t even at a testable state on Edge. Unfortunately, as a result, our site just throws up “Edge support in development” when it’s visited. I’m a fan of the new browser, and I’ll be happy to throw that page out as soon as possible; plus, I’m pretty sure aside from that plugin snafu, most of our site looks great in Edge – the number of times that I have to perform browser-specific styling/functionality fixes gets smaller all the time; it’s just these major “functional web” things that get us running into trouble…

  7. As someone living in the dark ages of IE11 in compatibility mode and the prospect of having to dwell here for another year or more, I read articles like this with great hope and also frustration. We really need Microsoft to pull this off successfully so that we can stop the time-sucking wasteland of hacks to create and support code. I’m truly looking forward to the day when I can go in and pull out 90% of the entries between and ! Keep up the momentum and dialogue!

  8. Feature detection is great…. when it works.
    I am trying to get a WinJS app accepted on the Windows Store. Works great on desktops and the surface pro. Windows phone blows up immediately because I am calling the Web Audio API method navigator.mediaDevices.enumerateDevices. The method is there and I don’t see how feature detection will help me with this. When this code is executed on desktop edge, it works and calls back my handler with list of media devices. When this code executes on phone edge, it dies silently and the store testers blame my app for it.

    The only way I have been able to get around this is to check for “windows phone” in the user agent string and turn off the recording ability of the app. If phone edge every fixes the bug so it doesnt blow up in my face, killing my app, and taking me off the app store, I may take that user agent check out. In the mean time, its the only technique I’ve got to try and get on the store.

    Not sure why I am even writing this post. Its like talking to myself in a dark room…..