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:

(Interestingly, there was some disagreement about this pattern's validity when I removed the <title> tag. 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!).

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.

[…] 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) […]

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.

@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.

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.

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).

@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!

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 :).

[…] boilerplates and styling for HTML 5 so to give you all a helping hand and continue on from those basic building blocks that Remy talked about last week I’ve created a HTML 5 reset stylesheet for you to take away and […]

(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.)

[…] 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. […]

I updated the article by removing <dialog>, and adding <details> and <figcaption>.

@jody content='text/css' is not allowed:

The type attribute gives the styling language. If the attribute is present, its value must be a valid MIME type that designates a styling language. The charset parameter must not be specified. The default, which is used if the attribute is absent, is “text/css“.

I see that “http-equiv=”Content-Type” content=”text/html” are no longer required/recommended with html5 but I also see a lot of html5 sites(eg. google) still including it. I presume because 1) it doesn’t hurt anything , and 2) it helps older browsers. Should I enforce the leaner html5 header by omitting this, for stylistic reasons, and to save a few bytes, or include to get along in the bigger world?

direct line insurance company is allowing third party fire and theft insurer to drive another carhttp://www.box.net/shared/gtvdmdtm7f
direct line insurance company is allowing third party fire and theft insurer to drive another carhttp://www.box.net/shared/gtvdmdtm7f
direct line insurance company is allowing third party fire and theft insurer to drive another carhttp://www.box.net/shared/gtvdmdtm7f

really liked what that you published actually. it really isn’t that simple to find great stuff to read (you know.. READ! and not just browsing through it like some zombie before going somewhere else), so cheers mate for really not wasting my time! :D

[…] people ask about templates, boilerplates, and styling for HTML 5. Last week, Remy introduced some basic boilerplates for HTML 5, so to keep the momentum going, I’ve modified Eric Meyer’s CSS reset for you to use in your […]

Definitely consider that which you said. Your favorite reason seemed to be at the web the simplest factor to take note of. I say to you, I definitely get irked whilst folks consider concerns that they just don’t understand about. You managed to hit the nail upon the top and also defined out the whole thing with no need side-effects , other folks could take a signal. Will likely be back to get more. Thanks

Even though it’s almost four years later(!), I notice no one ever responded to you. As to why everyone is making “DOCTYPE” uppercase when it doesn’t have to be, I can only guess/assume because it’s “supposed” to be.

HTML is not case sensitive, so anything goes. However, if you use the XML serialization of HTML5, the XML parser will return an error. And if we ever return to XHTML, the practice of lowercase tags and an uppercase DOCTYPE will have you good to go.

Regardless, I’m curious why the one instance of an uppercase DOCTYPE at the beginning of the document is so distracting to you.

@solstice,

The “self-closing” tag syntax is optional, both > and /> validate. Some people prefer it the first way (and claim simplicity), others the second (and claim legibility).