In this post, we are sharing a list of legacy IE technologies and features that are not part of Microsoft Edge. Not supporting these legacy technologies in Microsoft Edge has a number of benefits: better interoperability with other modern browsers, improved performance, security & reliability, and reduced code complexity, just to name a few. And just like all good developers, ours love to delete code – over 220,000 lines of code in MSHTML have been removed from Microsoft EdgeHTML!

We’re also sharing more about how we plan to introduce new web platform features to Microsoft Edge using concepts like feature flags and API trials, with the goal of preserving the ability to experiment with new capabilities which eventually lead to stable, interoperable implementations across browsers.

Technologies and APIs not supported in Microsoft Edge

Here are some key technologies which will not be supported in Microsoft Edge. A number of these had been deprecated in the past few releases, but moving to a new engine allows us to remove support completely. To ensure future compatibility with Microsoft Edge and other modern browsers, we recommend against any future development or deployment of these technologies. These technologies will continue to be supported in Internet Explorer on Windows 10 for users and enterprises who depend on them.

Technology

Why it existed

Why we don’t need it anymore

ActiveX

ActiveX is a binary extension model introduced in 1996 which allowed developers to embed native Windows technologies (COM/OLE) in web pages. These controls can be downloaded and installed from a site and were subsequently loaded in-process and rendered in Internet Explorer.

The need for ActiveX controls has been significantly reduced by HTML5-era capabilities, which also produces interoperable code across browsers. Microsoft Edge will support native PDF rendering and Adobe Flash as built-in features rather than external add-ons.

We recently demonstrated our early work on a modern, HTML/JavaScript-based extension model to provide extensibility beyond what is available with HTML5. We will enable this new model after our initial release of Microsoft Edge this summer and we look forward to sharing more details soon.

Browser Helper Objects (BHO)

BHOs are a binary extension model introduced in 1997 which enabled developers to write COM objects that were loaded in-process with the browser and could perform actions on available windows and modules. A common use was to build toolbars that installed into Internet Explorer.

Document modes

Starting with IE8, Internet Explorer introduced a new “document mode” with every release. These document modes could be requested via the x-ua-compatible header to put the browser into a mode which emulates legacy versions.

Similar to other modern browsers, Microsoft Edge will have a single “living” document mode. In order to minimize the compatibility burden, features will be tested behind switches in about:flags until they are stable and ready to be turned on by default.

Vector Markup Language (VML)

VML is an XML-based format for 2D vector graphics, originally proposed in 1998 and originally supported in IE5.

Similar effects can be achieved using standards-based features in CSS3 and SVG.

In addition to ActiveX and BHOs, there are a number of other legacy extensibility points that are not in Microsoft Edge and will be replaced by a unified, modern extensibility model. These include:

Binary behaviors

Pluggable protocols

Shell Helper API

Active Documents

Custom Download Managers

Custom Security Managers

MIME filters

Custom Print and Print Preview Handlers

Explorer Bars

Edit Designers

Timers

Accelerators

Webslices

There are also hundreds of other non-interoperable APIs which have been removed. In most cases, these APIs now have interoperable, standardized replacements—removed APIs do not necessarily mean removed capabilities. All too often, the presence of these non-interoperable APIs cause site compatibility issues. Removing them makes a substantial improvement to user experience in Microsoft Edge and doubles down on our commitment to the web’s best feature: interoperability.

Preserving interoperability and experimentation on the web

Some of the more notable removals are those where Microsoft Edge supports the latest standard API definition and removes support for MS prefixed versions of the APIs. Examples include CSS Transforms, Fullscreen API, and Pointer Events. This brings up an important topic: vendor prefixes. You’ll see a trend in the vendor prefixes in Microsoft Edge compared to IE:

Our support (or lack thereof) of prefixed APIs is data-driven with compatibility as the sole purpose for any that remain. As examples, -webkit-border-radius is still in use on over 60% of page loads and the MS-prefixed Encrypted Media Extensions APIs are still in use on top video streaming services. Because of the impact on interoperability across the Web, these are supported in Microsoft Edge for the time being.

The consensusacross theindustry is that vendor prefixes cause more harm than good and the necessity of browsers supporting other vendor’s prefixes is a good example of why. Going forward, we’re using feature flags (accessible by navigating to about:flags) to introduce experimental APIs and minting new vendor prefixed APIs sparingly, if ever. Today, you’ll find examples like early implementations of CSS Filters, Touch Events, and HTML5 date inputs in about:flags. We’re also working with other browser vendors on exploring new approaches to experimental APIs that enable easier and broader access to experimental APIs while minimizing the compatibility burden that prefixes incur. Check out this talk (starts around 31 min mark) for an initial proposal we’ve made, tentatively named “API Trials”.

Ready for the future

We hope that this provides some insight into of how Microsoft Edge is leaving behind some legacy in order to provide a great foundation for the future. Please continue to test your sites in Microsoft Edge via the Windows Insider Program or RemoteIE, and give us your feedback via @MSEdgeDev or Connect.

If you have any questions about legacy technologies in Microsoft Edge, or about Microsoft Edge in general, join us live at 2:30 PM PDT on Channel 9 for an open Q&A with the Microsoft Edge engineering team! We’ll be taking audience questions from Microsoft Edge Web Summit attendees, as well as questions to @MSEdgeDev on Twitter with the hashtag #AskMSEdge.