HTML5 Boilerplates

Without going into the discussion of why HTML 5 is available today and not 2022, this article is going to give you a series of HTML 5 boilerplates that you can use in your projects right now.

HTML 5 in 5 seconds

It’s über easy to get your markup to validate as HTML 5 — just change your DOCTYPE from whatever it is now to this:

<!DOCTYPE html>

That's it! It doesn't require anything more than that.

Google are doing it already. Check out their homepage, written all in one line:

<!doctype html><head><title>HTML 5 - Google Search</title><script>...

Ironically, Google's search and results pages don't validate because of their use of invalid tags like <font> and a number of other errors, but that's okay. They can still take advantage of the HTML 5 parsing rules (e.g., no type attribute on the <script> element) by using the correct DOCTYPE.

HTML 5 minified

If you like to knock out quick prototypes or experiments that don't require much styling, you might be interested in a miniature document in HTML 5:

<!DOCTYPE html>
<title>Small HTML 5</title>
<p>Hello world</p>

That's completely valid HTML 5 too.

(Interestingly, there was some disagreement about this pattern's validity when I removed the <title> tag. Hixie's DOM viewer says it's fine, and so does the W3C validator as long as the markup is entered manually. But Henri Sivonen's validator says it's invalid without the <title> tag. The W3C validator also says it's invalid when you give it a url. Hopefully, this will get sorted out soon.)

HTML 5 complete & compatible

This final, more complete boilerplate also indicates the character set. Without it, some characters will not render properly (and I've spent too much time in the past trying to work out why!).

We're also including the HTML 5 shiv so that we can style elements in IE. Note that you must include this script in the <head> element.

Finally, we're adding a few CSS rules to cause the new block-level elements to render as such, since some browsers don't know about them natively.

So here it is — a valid and complete HTML 5 document boilerplate:

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>HTML 5 complete</title>
<!--[if IE]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
<style>
  article, aside, dialog, figure, footer, header,
  hgroup, menu, nav, section { display: block; }
</style>
</head>
<body>
<p>Hello World</p>
</body>
</html>

If you want to experiment with HTML 5, I've created a template over at JS Bin for you to play with too.

Share and Save:
  • Twitter
  • Digg
  • Sphinn
  • Reddit
  • del.icio.us
  • StumbleUpon
  • Technorati
  • Netvibes
  • Facebook
  • Google Bookmarks
  • FriendFeed
  • HackerNews
  • LinkedIn
  • NewsVine
  • Tumblr

41 Responses to “ HTML5 Boilerplates ”

Comment by Shaun at

Thanks, this hopefully this should lead people away from (incorrectly) using XHTML.

Perhaps you should also mention that HTML5 doesn’t mind if you close your tags in XHTML fashion (like ).

I am going to be teaching my partner HTML and CSS, this certainly makes things simpler!

Comment by Edward O'Connor at

Some corrections:

“The way to get the browser to switch to HTML 5…”

The browser doesn’t switch to some kind of new HTML5 mode when seeing the doctype. There isn’t a new HTML5 mode, there’s still only quirks mode, almost standards mode, and standards mode. The doctype specified in HTML5 triggers standards mode, but so does the HTML 4.01 doctype etc.

The Live DOM Viewer isn’t a validator, it’s a development tool. Keep in mind that browsers build a DOM from valid and invalid documents alike–the DOM Viewer lets you see that DOM for any input bytes.

Comment by rascunho » Blog Archive » links for 2009-07-17 at

[...] HTML 5 Boilerplates | HTML5 Doctor A more complete boilerplate would be to include the meta character set, otherwise some characters aren’t going to render properly (and in the past I’ve spent too much time trying to work out why!). (tags: html5doctor.com 2009 mes6 dia17 HTML5 blog_post) [...]

Comment by Andy at

DOCTYPE in uppercase is also distracting. It calls out for our attention, away from other HTML code we are editing — that’s totally unnecessary.

Comment by jamesS at

@Adam,

Placing the style rules in the head ensures that they are applied every time the page is viewed. Otherwise, should the accompanying CSS file not get loaded for any reason then the browser would not render the new elements correctly.

Comment by Remy Sharp at

@Edward thanks for the corrections. I’m updating the blog post as you’re right on Hixie’s viewer – I initially thought this was parsing, but it’s actually reading the contents of how an iframe built the DOM tree – which explains why it’s handled differently.

Re: switching – of course you’re right. There’s no mode to switch in to, I think it’s more the way of thinking about the way we’re writing our code. I’ve updated the post to read “validate as HTML 5″ which is what I was aiming for ;-)

@Juraj – you could strip the trailing p tag, but preference is to use “well formed” markup. Just because it’s reduced, doesn’t mean it needs to look like the bad old days of HTML 4 :-)

@Adam – as Shaun said, you can include these styles in your external files, it doesn’t particularly have to be inline. Check out the source code to HTML 5 Doctor, we include the HTML 5 styles in the reset styles that we use.

Comment by Wired Earp at

Save for the audio + video + canvas tags, I have never felt much enthusiasm for HTML5. Well, some other aspects are cool, but the “minified” document example certainly doesn’t help. Oh lord. If markup is supposed to authored by monkeys, I propose that we also spec out a version of Javascript with optional use of quotes, brackets and curly brackets. Creating a website should be no harder than driving a car into a wall. I am sure we will all benefit from this.

Comment by Remy Sharp at

@Wired Earp – just to repeat myself, the minified example I gave was for those developers who want to create “quick prototypes or experiments”.

Here’s an example (by Simon Willison): http://json-time.appspot.com/

Check the source, are you suggesting that he should have included all the markup to make it more…well more “less available to monkies” (I guess)?

I for one welcome the strict parsing definitions in the HTML 5 spec. I means I don’t have to repetitively include long doctypes that I never remember (and I’ve seen developer incorrectly copy from other documents), it mean I don’t have include the type attribute on the script element (yay, because it defaults!).

Oh, and nice side benefit: less bandwidth is taken up (which is important for any large web site obviously).

Comment by Wired Earp at

@Remy – I realize that you must be repeating yourself a lot in this discussion, but for me, this comment was a first on the subject – and I’ve been subscribed to the WHATWG mailing list since day one, so there’s been time to build up steam.

By making the page available to monkeys, the author has made it unavailable to me. In a minified document, can I rely on the notion of document.body in any Javascript I might add to the page? Can I address document.documentElement anywhere? Can I dynamically load scripts into the head section of the page? Can I read the innerHTML of some element to analyze the structure of the document? HTML5 parser implementations may implicitly expose these objects to me (I hope), but the claimed simplification of markup has undoubtedly made Javascript more abstract and unattainable to, well, monkeys.

In CSS, I commonly prefix a declaration with “html body” to make it more specific, because I rely on these tags to be present in the document. I my XSLT, I often match the root HTML tag in my template, because I know that it is there. But now I can’t even trust the presence of a root tag, which is required for XSLT, even if my document is lucky enough to be well-formed in the first place. This one minute of time saved by the markup author adds days of confusion and bewilderment to my schedule. While HTML has been made simpler to the markup author – though easily the simplest development discipline to begin with – associated technologies have been made dependant, once again, on tag soup cleanup engines, crash test scenarios and conditional branching based on regular expressions.

I’m in the process of converting our company’s website to HTML5 in my spare time, so don’t get me wrong, I like major portions of the package. I just happen to believe that complex macro structures arise as an emergent feature of tight organization on the micro scale. I don’t believe that a bohemian HTML5 interpretation is similar-to-but-better than strict XHTML for the exactly the same reason that I don’t believe that an optional ordering of amino acids in my DNA chain will somehow not affect my personality. Looseness at the level of fundamental building blocks is a cause for the problems we face here, not the cure that everybody appear to expect.

I’ve been around long enough to know that the next phase in this race will be a collective migration towards well-formedness and tighter conventions, so I’m not really worried, just a little frustrated that the egg seems to have beaten the chicken in the short run. Thanks for running this awesome resource!

Comment by SelenIT at

@Wired Earp

You found the great analogy between HTML5 and genetic code :) . One of the fundamental features of the genetic code is redundancy: each amino acid (the basic structure for building proteins — may be compared to DOM elements in web page constructing) can be coded with several basic nucleotide sequences in the DNA, which may be compared to the markup syntax variations. Similar redundancy helps the HTML page (but not the XHTML in XML mode) produce steady DOM structure even in case of small “mutations” in the markup. I don’t think that it is ‘looseness at the fundamental level’ because the new rules of markup interpretation (described in HTML5 spec) have no ambiguity — exactly as the rules of genetic code :) .

Comment by jody at

Is the meta tag for CSS, “content=’text/css’”, still required? W3C language for HTML 4 was that the meta tag “should” be included.

Comment by Oli at

@remy changes needed here too :)

article, aside, dialog, figure, footer, header, hgroup, menu, nav, section</blockquote

Should be: “article, aside, details, figure, footer, header, hgroup, menu, nav, section”

It never ends huh!

Comment by Mathias Bynens at

(Interestingly, there was some disagreement about this pattern’s validity when I removed the tag. Hixie’s DOM viewer says it’s fine, and so does the W3C validator as long as the markup is entered manually. But Henri Sivonen’s validator says it’s invalid without the tag. The W3C validator also says it’s invalid when you give it a url. Hopefully, this will get sorted out soon.)

The TITLE element has recently been made optional in some special cases, e.g. when HTML is used as an e-mail authoring format. In all other cases (including your example), a TITLE element is required.

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <b> <blockquote cite=""> <cite> <del datetime=""> <em> <i> <q cite=""> <strong>

You can also use <code>, and remember to use &lt; and &gt; for brackets.