6 Web Development Myths about Microsoft Edge
This article is part of a web development series from Microsoft. Thank you for supporting the partners who make SitePoint possible.
You may (or may not) have heard, Microsoft Edge is the default browser for Windows 10 and has a completely different rendering engine (EdgeHTML) which renders HTML5 Web Standards more like Chrome, Firefox, and Safari browsers than older versions of Internet Explorer.
That should be good news for web devs especially when you combine the news that Microsoft has ended lifecycle support for IE8, IE9, and IE10 too. Microsoft Edge is also very different from other versions of IE since there are no BHOs (Browser Helper Object) or ActiveX components other than PDF or Flash.
But with all this progress, I’ve also observed web developers on social media or forums showing off code that may web apps are not taking full advantage of Microsoft Edge, although they think it works, their code is still treating Microsoft Edge more like Internet Explorer than Chrome, Firefox, or Safari. Maybe some developers are assuming that Microsoft Edge is IE11–let me tell you this, Microsoft Edge IS NOT IE11. So I’d like to address the myths that web developers sometimes assume or may be unaware of about Microsoft Edge browser. Maybe, maybe not; anyway, I just want to help by sharing this. So, let’s look at six top web development myths about Microsoft Edge.
Microsoft Edge is using Trident rendering engine.
FACT CHECK: FALSE!
How to Check This
To identify the Microsoft Edge and EdgeHTML version, just go to Settings (the dot-dot-dot icon on the top right) and scroll down to the bottom.
HTML Document Declaration. Some developers think that Microsoft Edge does not/cannot use this line:
FACT CHECK: FALSE!
The truth is the Microsoft Edge browser is better off using the HTML5 document type and telling the browser EdgeHTML to render as an HTML5 document. In fact, Internet Explorer 9+ has supported
<!DOCTYPE html> in similar manner.
How to Use It?
Use at the top or the first line in the HTML document before
<head /> element. Example:
In a Microsoft Edge HTML document, we need to add meta information, which is the User Agent (UA) compatibility as ‘Edge‘. That is:
<meta http-equiv="X-UA-Compatible" content="IE=edge">
FACT CHECK: FALSE!
The truth is ‘NO‘, you do not need to add this line. Even if you targeted IE11 browser, there’s no need to add this meta information. It does not require or even has any function in the Microsoft Edge browser.
How To Resolve This
http-equiv=”X-UA-Compatible” meta tag on the HTML document. What if you need the site to be compatible with old browsers such as IE8, IE9 or IE10? See Myth #4 and #5 below.
To be compatible with Edge browser, I must detect or sniff the browser User Agent string (UA String) before requesting content from the web server, so when the server respond, I can return the correct HTML version accordingly.
FACT CHECK: FALSE!
The truth is, you must avoid any sniffing or detecting browsers User Agent string for conditioning request to the web server. You should just return any request as HTML5 Web Standards contents. In some cases, you may need to sniff the browser UA string, but make sure it’s only for checking purpose and not for conditioning of web server responses. Why? Because HTML layout/rendering engine is a fault tolerant declarative language. It wouldn’t block HTML document even if you throw any non HTML syntax. However, don’t abuse the HTML document with junk or some trash text.
How to Resolve This
There are several ways to resolve this. First, you must remove any client or web server side code that has UA sniffing for conditioning web server responses based on that UA string. Try to avoid this–this is not recommended in HTML5 Web Standards. Make sure you have a clean HTML document. Remove any non HTML web standards syntax.
Some say, “What if I need to know whether the browsers support certain features?”
Here is the output on Microsoft Edge:
And here is on Microsoft IE6. Wait! What… IE6? Yes, I also tried it on IE6 for testing. It does not mean you should use IE6 instead. Is just to proof that the HTML5 code works because browsers’ HTML layout/rendering engine are fault tolerant. It renders what it understand.
FACT CHECK: FALSE!
Don’t always blame the browser; there are many factors that go into performance including certainly standards-compliant code on a site. Here are the latest benchmark across popular tests; you can see the impact of Chakra’s improvements:
How to Optimize This
My web app is for LOB (line of business) and is for internal use only (Intranet). We don’t need to migrate to support Microsoft Edge now, since HTML5 will not be ready before year 2022.
FACT CHECK: SUPER FALSE!
HTML5 is here. Your intranet app should be migrated to HTML5 now or otherwise you should consider your migration plan to HTML5 at least on the year 2013 as modern browser continue to be deployed across organizations. While IE11 now has legacy emulation to help make the path towards migration more smooth, there are still performance, usability, and just the maintenance of one standards-compliant code base to consider. Just imagine if your colleague wants to use the latest mobile phones for accessing the intranet from outside of the office building. They cannot do that since mobile browsers did not support legacy web. There is no ActiveX, no Silverlight and no custom plugins that can be used. It’s time to use HTML5 now.
How to Migrate
Here are some small myths that I observe and what you should do.
- Most enterprises still use Windows 7–we cannot migrate: Well, you can install IE11 or the latest version of Chrome or Firefox if you want to make it work in HTML5. You can start migrating slowly to target IE11, BUT, please use HTML5 as your plan for migration. So, not just browser migration plan. Do HTML migration plan as well.
- My intranet requires ActiveX for our LoB app: No problem, you can use IE11 or the latest version of Chrome or Firefox while you are planning for migration. Use it as a temporary migration process. Slowly remove any BHO (browser helper object), such as ActiveX Plugins, and replace with new web app development with HTML5 Web Standards. It’s more secure and provides better performance.
- You don’t understand, we have hundreds of intranet web app: Personally I do understand. That is why you need a plan to migrate. Put it like this, the migration to HTML5 is your priority and you need to do it starting now.
- I use 3rd party products for the intranet web app: Contact the vendors and ask for the updated HTML5 one. If they don’t have it, don’t use it. Use the one that has up-to-date one. My suggestion, if the vendor is using ActiveX, than replace it with proper HTML5 Web Standards only.
Conclusion: Use HTML5 Web Standards
Use HTML5 Web Standards if you want to target all modern web browsers. Microsoft Edge and IE11 are modern web browsers. You don’t need to worry about compatibility as long as you use proper HTML5. Proper HTML5 means this:
- Ensure HTML5 Rendering Mode on first line. Yes this one line .
- Avoid Browser Sniffing and Detection for conditioning request based on browsers’ User Agent string.
- Avoid vendor specific CSS Prefixes. You cannot have the same browser features in all browsers. Therefore use the standards HTML5 one that has been rectified and supported in all modern browsers.
More Hands-on with Web Development
We encourage you to test across browsers and devices including Microsoft Edge – the default browser for Windows 10 – with free tools on dev.microsoftedge.com:
- Scan your site for out-of-date libraries, layout issues, and accessibility
- Download free virtual machines for Mac, Linux, and Windows
- Check Web Platform status across browsers including the Microsoft Edge roadmap
- Remotely test for Microsoft Edge on your own device
More in-depth learning from our engineers and evangelists:
- Interoperability best practices (series):
- Coding Lab on GitHub: Cross-browser testing and best practices
- Woah, I can test Edge & IE on a Mac & Linux! (from Rey Bango)
- Unleash 3D rendering with WebGL (from David Catuhe)
- Hosted web apps and web platform innovations (from Kiril Seksenov)
Our community open source projects:
- manifoldJS (deploy cross-platform hosted web apps)
- babylonJS (3D graphics made easy)
More free tools and back-end web dev stuff: