Learning from the HTML5 Boilerplate, Part 2

The HTML5 Boilerplate is well-known across web programmers as a powerful starting template for (as the project homepage puts it) building fast, robust, future-proof sites. Out of the box, it provides HTML, CSS and Javascript code arranged in such a way to drive as much oomph into your pages as possible. Every nook, cranny, and design decision borrows from widely-accepted standards, and is supported by countless hours of research and testing.

While the HTML5 Boilerplate is awesome as a starting foundation for building awesome sites, it is also packed with code snippets and patterns you should be using for your projects. Just in case you’re not using the HTML5 Boilerplate for some reason.

Making Internet Explorer behave

As if it wasn’t enough that web developers had to keep track of different Internet Explorer versions, it must also be said that computers that run IE also have multiple rendering engines. That is, if a user had IE 8, for example, you can be sure that it has the IE 8 rendering engine. However, it also has a readily available mock of the IE 7 engine as well, so a version 8 Internet Explorer may render a page as if it was version 7. If that wasn’t enough, it must also be said that these rendering engines aren’t exact copies: a version 8 IE using the version 7 rendering engine will not behave in the exact same way as a true blue version 7 IE. And that sucks.

Circumstantially, sites viewed from an intranet also trigger Compatibility View, something like a glorified quirks mode, by default. That sucks even more.

As it turns out, you can explicitly tell Internet Explorer browsers to use its latest available rendering engine using a meta tag:

<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">

The IE=edge half of the meta value tells Internet Explorer to use its latest rendering engine for your page. That, in itself, is already a boon and a half.

The chrome=1 part tells it to use the Chrome Frame rendering engine if it is installed on the client computer, which basically brings Chrome rendering power to Internet Explorer (yes, even version 6).

Taking it one notch higher

Now, this doesn’t come without any imperfections. First of all, this won’t work completely as expected inside a conditional comment, so you might as well scratch that idea.

Secondly (and arguably more important to some), is that this line breaks validation. Now, to some, that can be quite a deal breaker.

If you’re absolutely picky about your HTML validation (’cause I’m most often not), a way to work around this is to send the meta value above as an HTTP header instead. That should work just as well.

If you are hosting from an Apache web server, you can send the X-UA-Compatible headers by editing your httpd.conf file and adding in the following:

<Location /mypath>
    Header set X-UA-Compatible "IE=edge,chrome=1"
</Location>

If you are serving off an IIS server, the easiest way to send a custom header is to set a custom configuration setting in your web.config file:

<system.webServer>
    <!-- ... -->
 
    <httpProtocol>
       <customHeaders>
           <add name="X-UA-Compatible" value="IE=edge,chrome=1" />
       </customHeaders>
    </httpProtocol>
 
    <!-- ... -->
</system.webServer>

Doing any of the above let’s you completely remove the tag from your markup.

You might want to read the other articles in this series as well:

• Part 1 : Conditional HTML tags