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. | 2D vector graphics are supported via Scalable Vector Graphics (SVG) which provides interoperability across modern browsers. |
| VBScript | VBScript is a scripting language modeled after Visual Basic. It was introduced in 1996 to provide web developers with a language option when scripting on the web. | JavaScript has become the de-facto language of the web and is evolving quickly with ECMAScript 6 and beyond. Microsoft Edge delivers the leading implementation of ES6. |
| attachEvent / removeEvent | IE8 and below supported a proprietary model for DOM events, which supported bubbling but not capture and used a global event object rather than passed as an argument to the event listener. | IE9 and above support the DOM Level 3 Events standard with addEventListener/ removeEventListener. |
| currentStyle | The currentStyle property retrieves the cascaded style of the element. | IE9 and above support the getComputedStyle property (part of DOM L2 standard) to retrieve the final computed style of any element. |
| Conditional Comments | Conditional comments provided a way to embed code that was only targeted at specific versions of Internet Explorer. | It is more effective to use feature detection and other progressive enhancement rather than browser specific code in conditional comments. |
| IE8 layout quirks | IE8 specific layout behaviors that were then emulated in later versions of Internet Explorer. | Most websites are written for standards-based layout. Sites that require IE8 specific behavior on the intranet can be rendered using Enterprise Mode. |
| DirectX Filters and Transitions | DX filters and transitions enabled web developers to apply various visual effects to elements on the web page. | 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
- Custom Context Menu entries (via registry)
- 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 consensus across the industry 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.
– Charles Morris, Principal Program Manager Lead, Microsoft Edge
– Jacob Rossi, Senior Program Manager, Microsoft Edge