Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
West Wind WebSurge - Rest Client and Http Load Testing for Windows

<main> HTML5 Tag not working in Internet Explorer 9/10/11


:P
On this page:

I was working on an my old Weblog code to tweak some of the markup a couple of days ago and ran into yet another issue with Internet Explorer: The HTML5 <main> element tag doesn’t appear to be working in any version of Internet Explorer. Now, this makes sense for versions prior to IE 9 since those versions had no support for HTML5 or ‘custom’ tags at all. But IE 9 and later do understand HTML5 elements like article, header, aside, nav etc. just fine, but for some reason the main tag is not working like the others. In fact it appears IE simply ignores the tag and treats it as if it wasn’t there.

For the most part IE 10 and 11 do a pretty good job with HTML5 that it’s rare that something doesn’t work, so a few days ago I posted my site without checking IE support (since this was such a minor change) and within 5 minutes I got a boat load of emails complaining that the site wasn’t working.

The <main> Tag in Internet Explorer

So when I recently updated my code on my blog recently to something like this:

<main class="post-content">
    <header>
        <h2>@Model.PostTitle</h2>
    </header>
    <article>
        @Html.Raw(Model.Content)
    </article>
</main>

everything worked fine in Chrome, FireFox and on my iPhone and Android phones. However, Internet Explorer – both on desktop and a Windows Phone – was completely mangled. In Internet Explorer – even IE 11 which supposedly is fully HTML5 compliant – I rudely found myself looking at the following mess:

IETrainwreck

The HTML was working fine with a <div> tag instead of the <main> tag previously. So the same page works perfectly fine with:

<div class="post-content">
    <header>
        <h2>@Model.PostTitle</h2>
    </header>
    <article>
        @Html.Raw(Model.Content)
    </article>
</div>

in Internet Explorer. What’s so odd about that is that IE has no problem with the header and article tags, but can’t handle the main tag.

Initially I wasn’t sure what caused this pile up to occur – it sure looks like what happens if you have an unclosed tag somewhere. But after some quick experimentation and switching the <main> tag back to a <div> tag I found that everything started working in IE. It was definitely the <main> tag that’s causing the problem.

The Quick Fix

I threw this IE shortcoming out on Twitter and promptly got a response from @aggeek:

TwitterHelp

So sure enough I added the following to my site wide CSS file:

main {
    display: block
}

and voila we’re back to a more sane site layout:

IeCorrect

It looks like IE treats the element as if it isn’t there or maybe treating it as an inline element. Looking in the IE dev tools I couldn’t find a computed value for the display style property which should mean that it defaults to display: block but that’s clearly not happening. Adding the display: block style explicitly fixed it. Honestly that would not have occurred to me on my own – as my inclination was to think the tag was essentially ignored.

The behavior is the same for any other ‘unknown’ tag in IE. If you replace main with foo you get the same behavior.

It’s probably a good idea to add the main { display: block; } to your Browser Reset stylesheet. In fact, it may be part of more modern Browser Resets, but in this case the reset I use is a a bit dated (as is the rest of the code on this site).

Ah yes, it’s quirks and inconsistencies like this that make most of us curse Internet Explorer. Why this one freaking inconsistency in HTML5 support?

Internet Explorer 8 and older

FWIW, HTML5 is not supported at all in IE 8 (which hopefully will start disappearing for good soon), but if you do plan on having IE 8 browser of which there are a still quite a few, accessing your site, you’ll need a shim to force IE8 to recognize the new HTML5 tags.

To make this work you can basically create a few fake elements in the DOM which effectively makes IE recognize HTML5 tags.

<script>
  document.createElement('header');
  document.createElement('section');
  document.createElement('main');
  document.createElement('article');
  document.createElement('aside');
  document.createElement('nav');
  document.createElement('footer');
</script>

A more common way to do this in a document is with a conditional script include in the HTML header of the document and referencing a script from CDN so that this script (and a few other polyfills) load only when the browser is actually IE 8 and lower:

<head runat="server"> <title></title> <!--[if lt IE 9]> <script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script> <![endif]—>
</head>

Nothing new any of this, but it’s one of those quirks you can run into longer after you thought you had all the HTML5 stuff figured out in terms of browser support. But even now IE continues to throw a wrench into things here and there.


The Voices of Reason


 

Jack
February 23, 2015

# Thanks!!

Thank you for this.
I was tearing my hair out wondering why IE was mangling my site.
Adding main{display:block} fixed it!

Sean W.
March 05, 2015

# re: &lt;main&gt; HTML5 Tag not working in Internet Explorer 9/10/11

I was a bit curious about this, so I hacked up a dirt-simple test case in JSFiddle. You can try it yourself (with jQuery):

Before main. <main>Foo</main> After main.
<script>console.log($("main").css("display"));</script>


Chrome prints "block" to the console. Firefox also prints "block". IE10 prints "inline".

The W3C and WHATWG recommend this should be the default style rule:

main { unicode-bidi: isolate; display: block; }


I ran the same test including "unicode-bidi" on a few browsers, and got these results:

Firefox 36: main { unicode-bidi: -moz-isolate; display: block; }
Chrome 40:  main { unicode-bidi: normal; display: block; }
IE 11:      main { unicode-bidi: normal; display: inline; }
IE 10:      main { unicode-bidi: normal; display: inline; }
IE 9:       main { unicode-bidi: normal; display: inline; }
IE 8:       main { unicode-bidi: normal; display: inline; }
IE 7:       main { unicode-bidi: normal; display: inline; }

// For comparison:
IE 10:      gronk { unicode-bidi: normal; display: inline; }

It's interesting that none of the three major browsers get the unicode-bidi property right by default. Firefox comes closest.

But these results suggests to me that the IE team simply forgot to include a stylesheet rule for <main>, since it shows the same properties as "gronk" or any other unknown element.

Rick Strahl
March 05, 2015

# re: &lt;main&gt; HTML5 Tag not working in Internet Explorer 9/10/11

@Sean - thanks for checking... and confirming what I suspected that main was treated as an inline tag.

Erx
January 13, 2016

# re: &lt;main&gt; HTML5 Tag not working in Internet Explorer 9/10/11

there are many tags of html5 that IE doesn't support and i have no idea why.

here is the main spec, scroll down and you'll see IE is crossed out.

http://www.w3schools.com/tags/tag_main.asp

Here are a list of tags, once clicked, you'll see at scroll down that IE doesn't support most of the HTML5 tags (tags with red 5 icon near tag name at main listing reference below):

http://www.w3schools.com/tags/default.asp

Why is this?

Henrik Vendelbo
July 21, 2016

# re: &lt;main&gt; HTML5 Tag not working in Internet Explorer 9/10/11

This is correct behaviour. Unknown tags are treated as inline. It is a sensible default. The main tag is a recent addition so you should forgive IE for not knowing it. You should have this in your reset stylesheet;

/**
* Add the correct display in IE 9-.
* 1. Add the correct display in IE.
*/

figcaption,
figure,
main { /* 1 */
display: block;
}

- ref: normalize.css

Rick Strahl
July 23, 2016

# re: &lt;main&gt; HTML5 Tag not working in Internet Explorer 9/10/11

@Henrik - it can be forgiven for IE 9, but not for IE 10 and 11 which claim to be HTML 5 compliant where those tags are not 'unknown' tags - these are bonefide HTML elements.

And again it doesn't really matter that IE might interpret the spec differently - the fact remains every other vendor got this right EXCEPT for IE which is enough reason IMHO that it should work the same especially given that IE has always been lagging the standards behind other browsers so the implmentation has been well known beforehand.

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2024