An Unofficial Guide to the HTML5 Boilerplate

October 13, 2010 • By

The HTML5 Boilerplate describes itself as “A Rock-Solid Default for HTML5” this is why we thought it would be useful to dive right into it and look at just what makes it such a great “base HTML/CSS/JS template for a fast, robust and future-proof site“.

Getting The Code

The latest version of the code itself can be found at, where you can download the latest commented or un-commented builds. If you scroll down a bit there’s also a well-highlighted version of the code which makes it really easy see just what it’s up to.

Getting Started – index.html

The first few lines the file will probably be a fairly common sight by now, the html5 doctype, the language defined on the html element and the new html5 charset declaration.

IE Comment – Fixing a performance issue

The first interesting snippet we come across is an empty html comment containing an if statement. This line of code simple checks if the browser is, in this case, any version of IE and if so executes whatever is inside the comments. That being, nothing.

<!--[if IE] >< ![endif]-->

This is simply to prevent a performance issue where a conditional comment would, in IE, cause the browser to download one file at a time rather than simultaneously, thus slowing page load times.

Making sure the latest version of IE is used

Versions 8 and 9 of Internet Explorer contain multiple rendering engines, this means that it’s possible to get stuck with a rendering engine other than the latest, so to fix this:

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

The meta tag simply tells the IE rending engine that; firstly, it should be using the latest, or edge, version of the IE rending enviroment, and that secondly, if already installed, it should use the Chrome frame’s rending engine. This just ensures that anyone browsing your site in IE is treated to the best possible user experience that their browser can offer.

Mobile Viewport – Creating a mobile version

The next key line that’s worth looking at is the Viewport meta tag:

<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0;">

As the comments above it (see the commented and online versions of the boilerplate) explain there are a few different options that you can use with this meta tag, if you’re interested you can find out more at (the Apple developer docs).

The two icons

The next few lines reference both the favicon and apple touch icon:

<link rel="shortcut icon" href="">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">

Both of these are used by multiple browsers and devices. The favicon.ico file is used on tabs, in title bars and bookmark menus of all the major browsers whilst the Apple Touch icon is used on all Apple’s iOS devices as well as by some, ironically enough, Android devices.

CSS Media and Caching

The CSS link is fairly straight-forward though it is worth mentioning that the media=”all” tag is implied simply by not including it. The interesting part of this link is the use of a query string ?v=1 on the end of the CSS url. This serves to force the browser to refresh its cache of the CSS each time this number is incremented as, so far as the browser can tell, a different file is being served.

This trick comes into its own when dealing with a site where regular updates to the CSS are commonplace and ensures that users are always seeing the latest version of the CSS, just be sure to increment the version number when you upload the new version of your stylesheet.

The second stylesheet reference is there for browsers, like Opera Mini (the lighter-weight younger brother of Opera Mobile), which aren’t as feature rich as the Mobile Safari and Android mobile browsers. This stylesheet is for anyone who’s still stuck on WAP, spare a thought.

Modernizr, Javascript and HTML class’

Modernizr is a Javascript library which hooks into the class attribute of the html tag (Line 2 in both versions of the boilerplate) and generates some useful classes as well as setting up all browsers to handle HTML5.

You would be forgiven for wondering why the HTML5 Shiv or Shim project hasn’t been included in this template, after all it uses Javascript to fix the issues IE and others have with rending HTML5. Actually the HTML5 Shiv is included, it’s a part of the Modernizr project, but that’s not all Modernizr does.

As well as improving HTML5 support, Modernizr also adds a series of class names to the html tag, where it initially says no-js, according to the browsers support for CSS3 and HTML5. This allows you to target parts of your CSS at only supporting browsers, leaving the rest to serve the plainer, albeit functional, version.

The Modernizr script is the only Javascript file loaded at the top of the document simply to keep page load times down, if a script is slow to load from an external server, it may cause the whole page to hang, this is avoided by calling any Javascript at the end of the page. That said, the Modernizr script needs to run before the browser begins rendering the page so that browsers lacking support for some of the new HTML5 elements are able to handle them properly.

After the Head Tag

IE body tag classes

The final part of the pre-content boilerplate is a series of ‘if’ statements detecting the IE browser version and applying the relevant class to the body tag. The benefit of this is that it allows CSS fixes for specific IE version without hacks such as:

div.this_element { float:right; margin-top: 10px; *margin-top: 5px; }

Which are commonly used to overcome bugs in the IE6 rendering engine and can be replaced, when using Modernizr, with:

div.this_element { float:right; margin-top: 10px; }
body.ie6 div.this_element { margin-top: 5px; }

The content of the boilerplate

The central part of the boilerplate template is pretty much empty. Paul Irish, one of the creators, explains that this is intentional in order to make the boilerplate suitable for both web page and web app development.

The Javascript

Towards the bottom of the page we find the final few lines of code, beginning with the jQuery library. Regardless of which Javascript library you make use of in your projects it is well worth the time and effort to look up and reference the Google CDN (Content Developer Network) version. In part because your users may already have this version cached in their browsers and also because the CDN will be far faster then your server could ever even dream of being.

The following line provides the page with a fallback should the CDN version of the jQuery library not be available, likely only if you are offline, this is one part you really can feel free to include or leave out at your leisure.

The next few line of code wrapped within the IE conditional statement:

<script src="js/dd_belatedpng.js?v=1">

Are a common fix for the IE6 issue with .png images, again if you aren’t bothered about supporting IE6 you can drop this part like a hot potato. If you do want so support IE6 then you can find more information on using this fix over at Diller Design.

Next up we get some code from Yahoo – we really are going round the houses today – which allows site profiling, like in Firebug or the Safari/Chrome developer panel, but which works cross-browser, including IE.

Finally we get the latest version of the Google Analytics tracking code, this latest version not only includes a few new handy tricks from an Analytics perspective but it also loads faster than the previous version. Google recommends that this script be placed at the top of the page, however it’s a matter of personal preference and whilst placing the script at the top will count users who don’t fully load the page, it does mean your page load time will take a slight hit, at least until anything shows on screen.

The End of Our Journey

That’s pretty much all there is to the index.html file in the boilerplate. If you head over to there are numerous links to articles on each line of code, so if there’s something you really want to get stuck into it’s well worth the time.