@boblet

lest I forget (Oli Studholme)

“Simon’s Cat ‘Fly Guy’ (via simonscat)”

I’m sure all cat owners can attest to the truth of this. Via adactio

Again I say: mammals and dinosaurs. Simon, along with everyone else who thinks online subscription fees can save the newspaper industry, is effectively arguing that the world will change to support newspapers. The truth is that newspapers must change to adapt to the world. Just because the extinction of newspapers would be a tragic loss doesn’t mean it won’t happen.

Pay Walls”, by John Gruber

Recently I’ve been reading a lot of articles on HTML 5 (such as on Zeldman.com and HTML 5 Doctor), and have seen a few reoccurring false perceptions in the comments. While some may seem funny for those following HTML 5’s progress closely, a lot of people aren’t, nor can they be expected to.

So in addition to the WhatWG FAQ, here are some common misunderstandings (and their explanations), written at a less technical level. My apologies for any overuse of the interrobang :)

  1. While a lot of the new stuff in HTML 5 isn’t widely supported, it’s important to remember one of HTML 5’s core principles is compatibility, eg with current content. Apart from a few minor differences most of the HTML 4/XHTML 1 spec is in HTML 5. For the new parts of HTML 5 (such as structural elements) support can often be added today via CSS and Javascript. Finally, modern browsers (and even IE) are implementing the HTML 5 spec now. While full compliance will take a while, there’s a lot that’s already usable, and support is increasing.

    Ref: When will we be able to start using these new features?—WhatWG FAQ

  2. IE doesn’t support HTML 5

    Internet Explorer is something of a … rugged individualist, resisting ‘trends’ (like standards support) and doing things it’s own way (cough .EOT cough) ;-). However as stated above because HTML 5 is mainly a well-defined HTML 4/XHTML 1 with sprinkles, all of the ‘old stuff’ still works. Unfortunately due to bugs, IE currently requires a Javascript hack to use new HTML 5 structural elements. For other new parts of the spec, Microsoft has been largely silent, but the IE team has already implemented Cross-origin resource sharing and Web storage in IE8 (IE Team blog), which were both parts of HTML 5 (and have been subsequently released as stand-alone specs). We can only hope that their well-deserved pride in implementing CSS2.1 completely carries over to HTML 5 and other specs.

    Ref: What about Microsoft and Internet Explorer?—WhatWG FAQ

  3. HTML 5 won’t be ready until 2022!?

    While this statement makes for good WTF-style headlines, it’s just not true. The 2022 date is for two complete implementations, something that has still not happened for HTML 4, XHTML 1.0 or XHTML 1.1. The dates to worry about are 2012 for a completed draft, and October 2009 for a working draft. That’s three months away yo! Also as stated above, browser makers are already implementing some of the new parts of HTML 5, and the rest is backwards compatible.

    Ref: When will HTML 5 be finished? and When will we be able to start using these new features?—WhatWG FAQ, and for fun Is HTML 5 Ready Yet? and Is HTML 5 Ready? ;-)

  4. You mean XHTML isn’t the future!?

    No, it’s the present. XHTML2 may be dead, but nothing will stop the millions of current XHTML 1.x pages (and any you create in the future) from working. However this probably means it’s a Good Idea™ to find out more about HTML 5 at some stage ;-)

    Ref: Differences Between HTML and XHTML; Parsing—WhatWG FAQ

  5. Now I have to relearn EVERYTHING!?

    Since HTML 5 is mainly a well-defined HTML 4/XHTML 1, and because both HTML- and XHTML-style syntax is allowed, you need to do very little (maybe only a doctype change) to change current well-made pages into HTML 5. While there are certainly new things to learn, we all like learning, right?

    Ref: HTML 5 differences from HTML 4—W3C Working Draft

  6. The HTML 5 spec isn’t understandable/is overly complex

    The HTML 5 spec is being written primarily for ‘implementors’—programmers who make web browsers and other tools to use the web. Unlike previous specifications, HTML 5 is defining processing steps and error handling explicitly, which can be a little overwhelming if you’re not a browser programmer :) Luckily a majority of the spec is actually just the HTML 4/XHTML 1 you already know.

    Also, there are already many useful articles and resources for author information on HTML 5, such as “A Preview of HTML 5” by Lachlan Hunt on A List Apart, “HTML 5 Reference” by Lachlan Hunt (a version of the spec specifically for authors) on w3.org, “HTML 5: The Markup Language” by Mike™ Smith (a pared down spec that removes implementor details) on w3.org, and sites like HTML 5 Doctor. You can also check out my humble HTML 5 articles :)

  7. HTML 5 means back to tag soup

    While the XML strictness in XHTML 1.0 and 1.1 certainly encouraged a move away from the bad old ways of the past, there’s nothing in HTML 5 (or HTML 4 either) that stops you from adding closing elements, correctly nesting elements, using elements appropriately, and generally making good code. HTML 5 is forgiving of mistakes, but you don’t have to make them :) Current HTML 5 validators are also already good (W3C, Validator.nu), and there is even talk of making a user-selectable ‘strict validator mode’, so if you want to write good code there’s nothing to stop you.

    Ref: Why does HTML5 legitimise tag soup?—WhatWG FAQ

  8. HTML 5 means ALL-CAPS element names

    HTML 5 is case-insensitive; both upper- and lower-case elements are permitted, even <!doctype html> ;-) Note that <!DOCTYPE html> is recommended just in case you ever need to use it in XHTML (which is case-sensitive).

  9. But I like XHTML-style closing slashes

    No one will take them away from you! XHTML-style closing slashes on empty elements are valid HTML 5, so you can write either HTML-style or XHTML-style HTML 5 (although it’d be best to consciously choose one and stick to it).

    Ref: Should I close empty elements with /> or >?—WhatWG FAQ

  10. HTML 5 contains presentational elements

    Some ‘presentational’ elements such as <small> and <i> from HTML 4 have been retained. This is because they now have defined semantic meaning—legalese (‘small print’) and a span of text in an alternate voice or mood, like a word from another language, respectively.

    A few of the new structural elements such as <aside> and <footer> can also be perceived as presentational, however the use of these elements should be dictated by their content and not their placement.

    Ref: Why are some presentational elements like <b>, <i> and <small> still included?—WhatWG FAQ

  11. HTML 5 isn’t as strict/pure/semantic as XHTML 1.x

    Also “HTML validators aren’t as strict as the XHTML validator”. While HTML 5 is more forgiving of mistakes than XHTML sent with a XML mime type, almost everyone used the text/html mime type, and in that case XHTML was treated as strictly as HTML 4 (or HTML 5) by browsers. HTML 5 actually defines element semantics more precisely than XHTML 1, and adds new semantic meanings (for <small>, <i> etc) and elements (<article>, <nav> etc). HTML 5 is also much more precisely defined, enabling better conformance checkers to be created, and current HTML 5 validators (W3C, Validator.nu) actually seem to be a little stricter than the XHTML 1 validator.

    Ref: the differences between HTML and XHTML—WhatWG FAQ

  12. HTML 5 is only what ‘Supreme Dictator for Life’ Ian Hickson deigns to accept

    The WhatWG and the W3C HTML 5 working group are using a different process to most other W3 projects—rather than the traditional ‘black box’ approach they accept input from anyone willing to give it, and decisions are not reached via consensus member voting. While this may seem to some like Hixie is basically playing god, he is actually working hard to base the spec on reality and achieve consensus with implementors, as they have the final say on what is implemented. So actually it would be more accurate to say HTML 5 is what the browser makers accept.

    Despite the exclusionary image some have, Hixie and other WhatWG & W3 HTML WG members read through and respond to a massive amount of feedback, via the WhatWG email list and W3 HTML email list, IRC, the bug tracker, and even weblog comments. In my experience they have been open to (and frequently requested) improvements. If you have some feedback, by all means engage with the HTML 5 community (preferably after having checked the official FAQ), giving examples of real-world usage and the pros and cons for your idea. If something is confusing ask for more information in a mailing list, or even better in IRC.

    Ref: WhatWG and W3C HTML Working Group

I hope that was of use. If you have any questions, feedback, or have found a mistake, please let me know via Twitter (@boblet)

We’ve covered a lot of ground so far. To recap, HTML5 has several new block-level sectioning elements that we can use to give relevant parts of web pages more semantic meaning. These new elements are for ‘chunks of related content’—basically a logical section of the document:

New sectioning elements in a nutshell

  • <section>—a chunk of related content
  • <article>—an independent, self-contained chunk of related content, that still makes sense on it’s own (eg in an RSS feed)
  • <aside>—a chunk of content that is tangentially related to the content that surrounds it, but isn’t essential to understanding that content
  • <nav>—navigation for the site or page
  • (cf. <div>—a chunk of content with no additional semantics, eg for CSS styling hooks)

With very few exceptions (generally in web applications) these new sectioning elements should have a title, possibly in a <header> element with any other introductory information. We can use this as a rule of thumb for deciding between <section> and <div>:

consciously add a title for each <section>, even if you then hide the title with CSS (as is generally the case with nav for accessibility). If it seems like content that shouldn’t have a title when CSS is disabled, then it’s most probably not a <section> (HTML5Doctor; The Section Element)

The new sectioning elements can also contain one or more <footer> elements with additional information, such as author (<address>) or copyright (<small>) info, related links etc. It’s important to note that <header> and <footer> (& <address>) apply to the sectioning element they’re in (this is <body> for a page header or footer). <header> and <footer> can’t contain other <header>s and <footer>s.

Finally, while the words “header”, “footer” and “aside” all come with preconceptions, their semantic meaning comes from the types of content they contain, not from their presentation or relative placement. For example, <aside> could contain a footnote, and a <footer> containing a ‘Top of Page’ link could appear at both the top and bottom of a section.

Now let’s look at example structures for a basic article page; using the standard layout of a page header (with logo etc), navigation tabs, a main column, a side column, and a page footer.

Article PageConverting a simple page to HTML 5#

Here’s the outline of the parts of our page:

Article Page Layout
  • Page header (site name, logo, search…)
  • Main navigation
  • Main content (wrapper)
    • Article (main column)
      • Article title
      • Article metadata
      • Article content…
      • Article footer
    • Sidebar
      • Sidebar title
      • Sidebar content…
  • Page Footer

So let’s write that in standard POSH HTML4:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
  <head>
    <title>Article (HTML4)</title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <div id="branding">
      <h1>Site name</h1>
      <!-- other page heading content -->
    </div>
    <ul id="nav">
      <li>Site navigation</li>
    </ul>
    <div id="content">
      <div id="main"> <!-- main content (the article) -->
        <h1>Article title</h1>
        <p class="meta">Article metadata</p>
        <p>Article content…</p>
        <p class="article-footer">Article footer</p>
      </div>
      <div id="sidebar"> <!-- secondary content -->
        <h2>Sidebar title</h2>
        <p>Sidebar content…</p>
      </div>
    </div>
    <div id="footer">Footer</div>
  </body>
</html>

So let’s write that in standard POSH XHTML1.0:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xml:lang="en">
  <head>
    <title>Article (XHTML1)</title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  </head>
  <body>
    <div id="branding">
      <h1>Site name</h1>
      <!-- other page heading content -->
    </div>
    <ul id="nav">
      <li>Site navigation</li>
    </ul>
    <div id="content">
      <div id="main"> <!-- main content (the article) -->
        <h1>Article title</h1>
        <p class="meta">Article metadata</p>
        <p>Article content…</p>
        <p class="article-footer">Article footer</p>
      </div>
      <div id="sidebar"> <!-- secondary content -->
        <h2>Sidebar title</h2>
        <p>Sidebar content…</p>
      </div>
    </div>
    <div id="footer">Footer</div>
  </body>
</html>

Now let’s convert that to HTML5, using the new structural elements:

<!-- 'HTML-style' HTML5 -->
<!DOCTYPE html><html lang="en">
  <head>
    <meta charset="utf-8"><title>Article (HTML5)</title>
  </head>
  <body>
    <header id="branding"><!-- page header (not in section etc) -->
      <h1>Site name</h1>
      <!-- other page heading content -->
    </header><nav><ul>
        <li>Main navigation</li>
      </ul>
    </nav><div id="content"> <!-- wrapper for CSS styling & no title so not section -->
      <article><!-- main content (the article) -->
        <header><h1>Article title</h1>
          <p>Article metadata</p>
        </header><p>Article content…</p>
        <footer>Article footer</footer></article><aside id="sidebar"><!-- secondary content for page (not related to article) -->
        <h1>Sidebar title</h1> <!-- ref: HTML5-style heading element levels -->
        <p>Sidebar content</p>
      </aside></div>
    <footer id="footer">Footer</footer><!-- page footer (not in section etc) -->
  </body>
</html>
<!-- 'XHTML-style' HTML5 -->
<!DOCTYPE html><html lang="en">
  <head>
    <meta charset="utf-8" /><title>Article (HTML5)</title>
  </head>
  <body>
    <header id="branding"><!-- page header (not in section etc) -->
      <h1>Site name</h1>
      <!-- other page heading content -->
    </header><nav><ul>
        <li>Main navigation</li>
      </ul>
    </nav><div id="content"> <!-- wrapper for CSS styling & no title so not section -->
      <article><!-- main content (the article) -->
        <header><h1>Article title</h1>
          <p>Article metadata</p>
        </header><p>Article content…</p>
        <footer>Article footer</footer></article><aside id="sidebar"><!-- secondary content for page (not related to article) -->
        <h1>Sidebar title</h1> <!-- ref: HTML5-style heading element levels -->
        <p>Sidebar content</p>
      </aside></div>
    <footer id="footer">Footer</footer><!-- page footer (not in section etc) -->
  </body>
</html>

Note here we assume that the sidebar contains content not related to the article (such as recent articles etc), so it’s a descendent of <body> (page sidebar) not <article>. If it only contained content tangentially related to the article we could use <aside>make <aside> a child of <article>. Also we assume that the <footer> doesn’t contain much more than a copyright statement and contact information—a detailed footer with headings etcpage header and footer don’t contain nested <header> or <footer> elements—a complex page header/footer requiring these would need it’s own <section>.

doctype, charset & XHTML-style markup#

You’ll notice the doctype and charset are both much simpler. HTML5 is case-insensitive, but WhatWG recommend this style of doctype as it will also work in XHTML (which is case sensitive). While this style charset is recommended, the pre-HTML5 charset declarations are still valid. Also, if you’re viewing XHTML-style code examples (there’s a handy HTML/XHTML code style switcher top right), you’ll note that the charset element still has an XHTML-style trailing slash in the HTML5 example. In fact XHTML-style markup (a closing / on empty elements) like this is also valid HTML5! This makes it very easy to migrate to HTML5 from both HTML and XHTML pages. You should try to avoid mixing HTML and XHTML-style code, however—choose one style and stick with it.

HTML5 or XHTML5? Choose HTML5#

If you currently use XHTML1.x you might be thinking to use XHTML5, the XML-compatible version of HTML5. If your website will have a general audience (=people using IE), don’t. XHTML5 must be sent with an XML mime type (like application/xhtml+xml), and even IE8 still doesn’t support this. However, all of the hallmarks of XHTML coding—writing elements in lower case, correct nesting, closing tags, adding optional elements that add meaning—are all compatible (HTML5 is case-insensitive) or encouraged in HTML5.

Browser support (via CSS and JS)#

So, does it work? Currently the HTML5 structural elements will work in modern browsers (Firefox 3+, Safari 3+, Opera 9+, Chrome 1+) as long as we declare them as block-level elements via this CSS:

/* Declaring HTML5 elements */
article,aside,details,dialog,figure,footer,header,hgroup,menu,nav,section{
  display: block;
  }

and in Internet Explorer 8 and below we need to hack support in via Javascript (I bet you didn’t see that coming ;-)

(function(){if(!/*@cc_on!@*/0)return;var e = "abbr,article,aside,audio,bb,canvas,datagrid,datalist,details,dialog,eventsource,figure,footer,header,hgroup,mark,menu,meter,nav,output,progress,section,time,video".split(','),i=e.length;while(i--){document.createElement(e[i])}})()

The recommended way to add this Javascript is via Remy Sharp’s Google Code-hosted HTLM5 shiv for IE in the page <head>:

<!--[if IE]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->

So, all together now…

<head>
  <!--[if IE]>
    <script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
  <![endif]-->
  <style type="text/css" media="screen"> /* Declaring HTML5 elements */
  article,aside,details,dialog,figure,footer,header,hgroup,menu,nav,section{
    display: block;
    }
  </style></head>

…but IE requiring JS means we’re screwed, right?#

You can easily choose to not worry about IE with Javascript turned off on a personal weblog, but if an IE user has JS disabled the new elements (and their associated styling) will be dropped, and the page will ass-plode (feel that déjà vu). While Javascript is becoming more of a requirement with the rise of web apps, IE needing Javascript will probably still be a show-stopper on commercial projects.

You might think that IE’s lack of support without Javascript for these new elements means you can’t use HTML5 at all, but there are two ways we can still benefit from HTML5’s greater semantic richness—by using HTML5 semantic element names as class names on <div> (so-called HTML4.5), in either HTML4/XHTML1.0 or HTML5. You’re probably already using a standard set of class and id names anyway, and this is in effect a standardised set of semantic class names. HTML5 is basically a superset of HTML4/XHTML1, so as long as you don’t use any new elements HTML5 pages will work in IE. It also has the benefits of simplifying a future move to HTML5, and if you use the HTML5 doctype you can also use the more detailed HTML5 validators.

Adding HTML5’s semantics via <div class="">#

Here’s the HTML4 version using HTML5 class names:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
  <head>
    <title>Article (HTML4), with HTML5 class names</title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <div id="page-header" class="header"> <!-- page header (note class="header") -->
      <h1>Site name</h1>
      <!-- other page heading content -->
    </div>
      <ul id="main-nav" class="nav">
        <li>Site navigation</li>
      </ul>
    <div id="content">
      <div id="main" class="article"> <!-- main content -->
        <div class="header">
          <h1>Article title</h1>
          <p>Article metadata</p>
        </div>
        <p>Article content…</p>
        <p class="footer">Article footer</p>
      </div>
      <div id="sidebar" class="aside"> <!-- secondary content -->
        <h2>Sidebar title</h2>
        <p>Sidebar content…</p>
      </div>
    </div>
    <div id="page-footer" class="footer">Footer</div>
  </body>
</html>

Here’s the XHTML1 version using HTML5 class names:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xml:lang="en">
  <head>
    <title>Article (XHTML1), with HTML5 class names</title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  </head>
  <body>
    <div id="page-header" class="header"> <!-- page header -->
      <h1>Site name</h1>
      <!-- other page heading content -->
    </div>
      <ul id="main-nav" class="nav">
        <li>Site navigation</li>
      </ul>
    <div id="content">
      <div id="main" class="article"> <!-- main content -->
        <div class="header">
          <h1>Article title</h1>
          <p>Article metadata</p>
        </div>
        <p>Article content…</p>
        <p class="footer">Article footer</p>
      </div>
      <div id="sidebar" class="aside"> <!-- secondary content -->
        <h2>Sidebar title</h2>
        <p>Sidebar content…</p>
      </div>
    </div>
    <div id="page-footer" class="footer">Footer</div>
  </body>
</html>

Now in HTML5, again using <div> with HTML5 class names rather than the new HTML5 elements:

<!-- 'HTML-style' HTML5 -->
<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Article (HTML5), with HTML5 class names</title>
    <meta charset="utf-8">
  </head>
  <body>
    <div id="page-header" class="header"> <!-- page header -->
      <h1>Site name</h1>
      <!-- other page heading content -->
    </div>
      <ul id="main-nav" class="nav">
        <li>Site navigation</li>
      </ul>
    <div id="content">
      <div id="main" class="article"> <!-- main content -->
        <div class="header">
          <h1>Article title</h1>
          <p>Article metadata</p>
        </div>
        <p>Article content…</p>
        <p class="footer">Article footer</p>
      </div>
      <div id="sidebar" class="aside"> <!-- secondary content -->
        <h2>Sidebar title</h2>
        <p>Sidebar content…</p>
      </div>
    </div>
    <div id="page-footer" class="footer">Footer</div>
  </body>
</html>
<!-- 'XHTML-style' HTML5 -->
<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Article (HTML5), with HTML5 class names</title>
    <meta charset="utf-8" />
  </head>
  <body>
    <div id="page-header" class="header"> <!-- page header -->
      <h1>Site name</h1>
      <!-- other page heading content -->
    </div>
      <ul id="main-nav" class="nav">
        <li>Site navigation</li>
      </ul>
    <div id="content">
      <div id="main" class="article"> <!-- main content -->
        <div class="header">
          <h1>Article title</h1>
          <p>Article metadata</p>
        </div>
        <p>Article content…</p>
        <p class="footer">Article footer</p>
      </div>
      <div id="sidebar" class="aside"> <!-- secondary content -->
        <h2>Sidebar title</h2>
        <p>Sidebar content…</p>
      </div>
    </div>
    <div id="page-footer" class="footer">Footer</div>
  </body>
</html>

You may be wondering why these two examples are so similar—after all, only the doctype and charset differ! That’s because one of HTML5’s core principles is compatibility. If we don’t use any new HTML5 elements, a change of doctype might be all that’s required to convert a well-coded HTML or XHTML page to HTML5.

Why bother with HTML5?#

So if you’re not going to use HTML5’s new elements, which IE doesn’t support without JavascriptHopefully by now you’re feeling excited about using HTML5 for a personal project. But if you’ve decided not to use HTML5’s new elements because IE doesn’t support them without Javascript, what’s the point of thinking about HTML5 now? I see several benefits:

  1. Thinking about HTML5’s structural elements (even if we only express the semantics via class names as described above) will make our code more logical and semantic
  2. HTML5 is defined in far greater detail than previous HTML/XHTML specs, giving us more guidance in creating web pages
  3. Another benefit of this detail is more accurate validators (W3C, Validator.nu), with the potential for more detailed error messages
  4. If you think you might convert to HTML5 in the future, the HTML-5-elements-as-class-names approach should remove a lot of the pain of converting (especially with a little regexp magic)
  5. Now that XHTML2 development will be halted, starting to learn about the official future of HTML is a Good Idea™
  6. Using HTML5 is a sliding scale, not all or nothing. You can get benefits from simply changing the doctype, a five second job.
  7. Because browsers use the same parser for HTML5 as HTML4/XHTML1, and because backwards compatibility is a central tenet, using an HTML5 doctype today has almost no disadvantages (make sure to check HTML5 differences from HTML4, specifically 3.3-3.5).

It’s possible to just change the doctype and get some benefits from having converted to HTML5 (when you use a validator :). However, the more time you put into HTML5 the greater the reward. You’ll get the most benefit from rethinking your site’s semantics from an HTML5 perspective, although for the present I’d recommend adding these extra semantics via the HTML-5-elements-as-class-names approach for commercial projects.

Questions? Feedback? Mistakes? Let me know via Twitter (@boblet)

Changes:#

  1. 2009-07-16 Added notes about doctype, XHTML5 and XHTML-style coding in HTML5, thanks to feedback from @robertdot. Also changed doctype to lower case in HTML5 code examples for consistency (HTML5 is case-insensitive so either is fine).
  2. 2009-07-19 Added headings for the doctype, charset & XHTML-style markup and HTML5 or XHTML5? Choose HTML5 sections I added last time, for better scanability. Added more info on the HTML5 shiv plus a copy-paste-able head code block for adding JS and CSS (thanks to HTML5 Doctor for the prompt). Also I added a few more links, a couple more points to “Why bother with HTML5?” (‘sliding scale’ and ‘no disadvantages’), rewrote the conclusion, and added what could be my favourite header ever.
  3. 2009-07-22 Added or rewrote these subtitles; Converting a simple page to HTML5 and Adding HTML5’s semantics via <div class="">. Changed “HTML5” to “HTML 5” etc.
  4. 2009-07-22 Reverted doctype to WhatWG-recommended XHTML-compatible style (although a lower-case doctype is fine in HTML 5!).
  5. 2009-09-16 Changed almost everything :)

Living with First-Person Shooter Disease

Meet Gene Simpkins, sufferer of moto-neural demyelination, or to the layman, Duke Nukem’s Disease…

Page 2 of 12