The HTML5 Shim vs Internet Explorer Emulation Mode

Craig Buckler
Craig Buckler
Share

In this article I’ll discuss techniques which are avoided by good HTML developers. Not everyone is as conscientious as SitePoint readers; you’ve probably encountered those who are happy to accept quick fixes regardless of the future pain it inflicts. When IE7 was released it broke sites designed for IE6. Developers had relied on IE6-specific techniques, workarounds and hacks which failed in the newer browser. Many sites had to be fixed. Developers deserve their share of the blame, but IE6 ruled supreme for many years so it’s not surprising people were annoyed by the changes. Microsoft were attacked even though they were only implementing the standards we demanded. To avoid a similar backlash in IE8, Microsoft introduced Document Compatibility modes. If your site worked in IE7 but failed in IE8, you could add the following meta tag to your page:


<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
or send an HTTP header:

X-UA-Compatible: IE=EmulateIE7
IE8 would mimic the behavior of IE7 and everything would magically work again. At the time of writing, IE9 features no less than eight Document Compatibility modes, including the slightly bizarre “IE5” setting which renders content as if it were displayed in IE7 quirks mode which is similar to IE5. For more details, refer to Defining Document Compatibility at MSDN. Document Compatibility mode is unique to Internet Explorer. Other browsers have not suffered the same fate because:
  • IE has been around longer than most of its competitors and evolved during a period when W3C standards were in their infancy. Other vendors were able to adopt a more stable set of HTML features from the start.
  • Microsoft sell software to businesses and have long-term contractual commitments. Other vendors can add, modify or drop features without facing legal or financial consequences.
  • Microsoft’s two-year IE release schedules inevitably contain more fundamental changes than regular updates to Chrome, Firefox, Safari and Opera.
Compatibility modes were intended to be a quick fix. If you encountered issues following an IE release you could temporarily use a compatibility mode while you updated your code. Does that happen? No. Look around the web today and you’ll find IE=EmulateIE7 meta tags everywhere. I’ve even seen it used on newly-released sites — after all, it’s easier to target one rendering engine than attempt cross-browser development in IE7, 8 and 9.

Compatibility Mode and IE9

Using IE5, IE7, EmulateIE7, IE8 or EmulateIE8 modes causes temporary amnesia for IE9. The browser forgets HTML5. It loses CSS3 effects such as rounded corners and box shadows. Features such as SVGs disappear. However, it also causes unexpected issues…

iframes and Other Child Objects

Let’s imagine you’ve created an HTML5 widget. It works in IE7, 8 and 9 because you’ve added the HTML5 shim:

<!--[if lt IE 9]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
Another developer now adds your widget to their site using an iframe. Not the most elegant solution, but it’s quick and easy. Question: if the parent page is opened in IE9 but uses IE=EmulateIE7, what rendering engine will the iframed page use? Answer: the parent page and all child objects — including the iframe — will render in IE7 mode. Even though your widget is IE7/8 compatible, your widget will break because:
  1. IE7, 8 and 9 render the iframe in IE7 mode, but
  2. the HTML5 shim is only loaded in IE7 and 8.
The result: IE7/8 work as expected but IE9 fails.

The Solution

It’s tempting to add a compatibility mode override to your widget’s HTML head, e.g.

<meta http-equiv="X-UA-Compatible" content="IE=edge" />
It won’t work. The parent page has overall control; it sets the rendering mode once and it remains that way until all assets have loaded. As far as I’m aware, there is only one fix — load the HTML5 shim in ALL versions of IE:

<!--[if IE]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
While IE9 and all future versions do not require the shim, you can’t guarantee your widget won’t ever appear in a page where a compatibility mode is set. Ughh — I feel unclean. Web development is a messy business.

Frequently Asked Questions about HTML5 Shim and IE Emulation Mode

What is the purpose of HTML5 Shim in Internet Explorer?

HTML5 Shim is a JavaScript workaround used to enable styling of HTML5 elements in versions of Internet Explorer (IE) that do not support them. It allows developers to use HTML5 elements in older browsers, particularly IE versions 8 and below, that do not natively support these elements. This is crucial because without the Shim, these browsers would not recognize the new elements and would not apply any CSS styles to them.

How does HTML5 Shim work?

HTML5 Shim works by creating the new HTML5 elements in JavaScript, which makes older versions of IE recognize them as valid elements. Once these elements are recognized, they can be styled and manipulated using CSS and JavaScript just like any other HTML elements.

What is the difference between HTML5 Shim and Shiv?

The terms Shim and Shiv are often used interchangeably, but they technically refer to two different things. A Shim is a library that brings a new API to an older environment, using only the means of that environment. On the other hand, a Shiv is a piece of code that solves a browser’s shortcomings by hooking into the browser’s internals.

How do I use HTML5 Shim?

To use HTML5 Shim, you need to include the following script in the head of your HTML document:
<!--[if lt IE 9]>
<script src="https://cdnjs.cloudflare.com/ajax/libs/html5shiv/3.7.3/html5shiv.js"></script>
<![endif]-->
This script should be included after any stylesheets so that all HTML5 elements can be styled correctly.

Are there any limitations to using HTML5 Shim?

While HTML5 Shim allows for the styling of HTML5 elements in older browsers, it does not add the functionality that some of these elements have in modern browsers. For example, the Shim allows you to style and use the new semantic elements like <header>, <footer>, and <article>, but it does not add support for form elements like <input type="number"> or <input type="range">.

What is the difference between HTML5 Shim and Modernizr?

Modernizr is a JavaScript library that detects HTML5 and CSS3 features in the user’s browser. While HTML5 Shim is included in Modernizr, they serve different purposes. HTML5 Shim allows older browsers to style HTML5 elements, while Modernizr detects whether the user’s browser supports certain HTML5 and CSS3 features.

Can I use HTML5 Shim in production?

Yes, HTML5 Shim can be used in production. It is a widely used and trusted solution for enabling HTML5 element styling in older browsers.

Does HTML5 Shim affect performance?

The impact on performance is minimal. The script is small and once downloaded, it is cached by the browser. However, as with any JavaScript, it’s important to test your website in all target browsers to ensure performance is acceptable.

Is HTML5 Shim still necessary?

With the decline in usage of older IE versions, the need for HTML5 Shim has decreased. However, if your website needs to support older browsers, then using HTML5 Shim is still necessary.

What are some alternatives to HTML5 Shim?

If you’re looking for alternatives to HTML5 Shim, you might consider using polyfills. Polyfills are scripts that allow developers to use modern functionality in older browsers that do not natively support it. However, it’s important to note that each polyfill only provides support for a specific feature, so you may need to use multiple polyfills to achieve the same level of support as HTML5 Shim.