Learning to Love HTML5


It seems that new resources and articles for teaching and promoting HTML5 are popping up almost daily. We’ve been given HTML5 templates in the form of the HTML5 boilerplate1 and HTML5 Reset2 (although they both go beyond just HTML5 stuff). We’ve got a plethora of books3 to choose from that cover HTML5 and its related technologies. We’ve got shivs4, galleries5, and a physician6 to help heal your HTML5 maladies. And don’t forget the official spec7.

From my own vantage point — aside from a few disputes8 about what the term “HTML5″ should and shouldn’t mean — the web design and development community has for the most part embraced all the new technologies and semantics with a positive attitude.

HTML5 for Web designers book9
Flickr Photo by Jeremy Keith10

While it’s certainly true that HTML5 has the potential to change the web for the better, the reality is that these kinds of major changes can be difficult to grasp and embrace. I’m personally in the process of gaining a better understanding of the subtleties of HTML5’s various new features, so I thought I would discuss some things associated with HTML5 that appear to be somewhat confusing, and maybe this will help us all understand certain aspects of the language a little better, enabling us to use the new features in the most practical and appropriate manner possible.

The Good (and Easy) Parts

The good stuff in HTML5 has been discussed pretty solidly in a number of sources including books by Bruce Lawson11, Jeremy Keith12, and Mark Pilgrim13, to name a few. The benefits gained from using HTML5 include improved semantics, reduced redundancies, and inclusion of new features that minimize the need for complex scripting to achieve standard tasks (like input validation in forms, for example).

I think those are all commendable improvements in the evolution of the web’s markup language. Some of the improvements, however, are a little confusing, and do seem to be a bit revolutionary, as opposed to evolutionary, the latter of which is one of the design principles14 on which HTML5 is based. Let’s look at a few examples, so we can see how flexible and valuable some of the new elements really are — once we get past some of the confusion.

An <article> Isn’t Just an Article

Among the additions to the semantic elements are the new <section> and <article> tags, which will replace certain instances of semantically meaningless <div> tags that we’re all accustomed to in XHTML. The problem arises when we try to decipher how these tags should be used.

Someone new to the language would probably assume that an <article> element would represent a single article like a blog post. But this is not always the case.

Let’s consider a blog post as an example, which is the same example used in the spec15. Naturally, we would think a blog post marked up in HTML5 would look something like this:

<h1>Title of Post</h1>
<p>Content of post...</p>

<p>Content of post...</p>

	<p>Comment by: Comment Author</p>
	<p>Comment #1 goes here...</p>
	</section> <section> <p>Comment by: Comment Author</p>
	<p>Comment #2 goes here...</p>
	</section> <section> <p>Comment by: Comment Author</p>
	<p>Comment #3 goes here...</p>

For brevity, I’ve left out some of the other HTML5 tags that might go into such an example. In this example, the <article> tags wrap the entire article, then the “section” below it wraps all the comments, each of which is in its own “section” element.

It would not be invalid or wrong to structure a blog post like this. But according to the way <article> is described in the spec, the <article> element should wrap the entire article and the comments. Additionally, each comment itself could be wrapped in <article> tags that are nested within the main <article> tag.

Below is a screen grab from the spec, with <article> tags indicated:

Articles nested in an article
Article tags can be nested inside article tags — a concept that seems confusing at first glance.

So, an <article> element can have other <article> elements nested inside it, thus complicating how we naturally view the word “article”. Bruce Lawson, co-author of Introducing HTML516, attempts to clear up the confusion in this interview17:

“Think of <article> not in terms of print, like “newspaper article” but as a discrete entity like “article of clothing” that is complete in itself, but can also mix with other articles to make a wider ensemble.”

— Bruce Lawson

So keep in mind that you can nest <article> elements and an <article> element can contain more than just article content. Bruce’s explanation above is very good and is the kind of HTML5 education that’s needed to help us understand how these new elements can be used.

Section or Article?

Probably one of the most confusing things to figure out when creating an HTML5 layout is whether or not to use <article> or <section>. As I write this sentence, I can honestly say I don’t know the difference without actually looking up what the spec says or referencing one of my HTML5 books. But slowly it’s becoming more clear. I think Jeremy Keith defines <article> best on page 67 of HTML5 for Web Designers:

“The article element is [a] specialized kind of section. Use it for self-contained related content… Ask yourself if you would syndicate the content in an RSS or Atom feed. If the content still makes sense in that context, then article is probably the right element to use.”

— Jeremy Keith, HTML5 for Web Designers

Keith’s explanation helps a lot, but then he goes on to explain that the difference between <article> and <section> is quite small, and it’s up to each developer to decide how these elements should be used. And adding to the confusion is the fact that you can have multiple articles within sections and multiple sections within articles.

As a result, you might wonder why we have both. The main difference is that the <article> element is designed for syndication, whereas the <section> element is designed for document structure and portability. This simple way to view the differences certainly helps make the two new elements a little more distinct. The important thing to keep in mind here is that, despite our initial confusion, these changes, when more widely adopted, are going to help developers and content creators to improve the way they work and the way content is shared.

Headers and Footers (Plural!)

Two other elements introduced in HTML5 are the <header> and <footer> elements. On the surface, these seem pretty straightforward. For years we’ve marking up our website headers and footers with <div id="header">, <div id="footer"> or similar. This is great for DOM manipulation and styling, because we can target these elements directly. But they mean nothing semantically.

“The div element has no defined semantics, and the id attribute has no defined semantics. (User agents are not allowed to infer any meaning from the value of the id attribute.)”

Mark Pilgrim, Dive Into HTML518

HTML5’s introduction of <header> and <footer> elements is the perfect way to remedy this problem of semantics, especially for such often-used elements. But these elements are not as straightforward as they seem. Technically speaking, if every website in the world added one <header> and one <footer> to each of their pages, this would be perfectly valid HTML5. But these new elements are not just limited to use as a “website header” and “website footer”.

A header is designed to mark up introductory or navigational aids, and a footer is designed to contain information about the containing element. For example, if you used the footer element as the footer for a full web page, then in that case copyright, policy links, and related content might be appropriate for it to hold. A header on the same page might contain a logo and navigation bar.

But the same page might also include multiple <section> elements. Each of those sections is permitted to contain its own header and/or footer element. Keith sums up the purpose of these elements well:

“A header will usually appear at the top of a document or section, but it doesn’t have to. It is defined by its content… rather than its position.”

“Like the header element, footer sounds like it’s a description of position, but as with header, this isn’t the case.”

— Jeremy Keith, HTML5 for Web Designers

And the spec adds to Keith’s clarification by noting:19

“The header element is not sectioning content; it doesn’t introduce a new section.”

The header element in the HTML5 specification20

These explanations help dispel any false assumptions we might have about these new elements, so we can understand how these elements can be used. Really, this method of dividing pages into portable and syndicatible content is just adding semantics to what content creators and developers have been doing for years.

Headings Down A Different Path

Prior to HTML5, heading tags (<h1> through <h6>) were pretty easy to understand. Over the years, some best practices21 have been adopted in order to improve semantics, SEO, and accessibility. Generally, we’ve become accustomed to including a single <h1> element on each page, with the other heading elements following sequentially without gaps (although sometimes it would be necessary to reverse the order).

With the introduction of HTML5, to use the new structural elements we need to rethink the way we view the structure of our pages.

Here are some things to note about the changes in heading/document structure in HTML5

  • Instead of a single <h1> element per page, HTML5 best practice encourages up to one <h1> for each <section> element (or other section defined by some other means)
  • Although we’re permitted to start a section with an <h2> (or lower-ranked) element, it’s strongly encouraged22 to start each <section> with an <h1> element to help sections become portable
  • Document nodes are created by sections, not headings (unlike previous versions of HTML)
  • An <hgroup> element is used to group related heading elements that you want to act as a single heading for a defined or implied section; <hgroup> is not used on every set of headings, only those that act as a single unit outside of adjacent content
  • To see if you’re structuring your document correctly, you can use the HTML5 Outliner23
  • Despite the above points, whatever heading/document structure you used in HTML4 or XHTML will still be valid HTML5

So, although the old way we structure pages does not amount to invalid HTML5, our view of what constitutes “best practice” document structure is changing for the better.

Block or Inline? Neither! (Sort of…)

For layout and styling purposes, CSS developers are accustomed to HTML elements (for styling and layout purposes) being defined under one of two categories: Block elements and inline elements (although you could divide those two into further categories24). This understanding simplified our expectations of an element’s display on any given page, making it easier (once we grasp the difference between the two) to style and manoeuvre the elements.

HTML5 evolves this concept to include multiple categories, none of which is block or inline. Well, theoretically, block and inline elements still exist, but they do so under different labels. Now the different categories of elements include:

I certainly welcome this kind of improvement to more appropriately categorize elements, and I think developers will adapt well to these changes, but it is important that we promote proper nomenclature to ensure minimal confusion over how these elements will display by default. Of all the areas discussed in this article, however, I think this one is the easiest to grasp and accept.


While this summarizes some of what I’ve learned in my study of HTML5, a far better way for anyone to learn about these new features to the markup is to pick up a book on the topic. I highly recommend one of those mentioned in the article, or you can read Mark Pilgrim’s book30 online.

These new elements and concepts don’t have to be confusing. We can take the time to study them carefully, avoiding confusion and dispelling myths. This will help us enjoy the benefits of these new elements as soon as possible, and will help developers and content creators pave the way towards a more meaningful web — a web that, to paraphrase Jeremy Keith, ‘wouldn’t exist without markup’.

Related Posts

You may be interested in the following related posts:


  1. 1 http://html5boilerplate.com/
  2. 2 http://html5reset.org/
  3. 3 http://www.webdesignerdepot.com/2010/05/html5-and-css3-books-to-watch-for-in-2010/
  4. 4 http://code.google.com/p/html5shiv/
  5. 5 http://html5gallery.com/
  6. 6 http://html5doctor.com/
  7. 7 http://dev.w3.org/html5/spec-author-view/spec.html
  8. 8 http://jeffcroft.com/blog/2010/aug/02/term-html5/
  9. 9 http://www.flickr.com/photos/adactio/4764451727/
  10. 10 http://www.flickr.com/photos/adactio/4764451727/
  11. 11 http://introducinghtml5.com/
  12. 12 http://books.alistapart.com/products/html5-for-web-designers
  13. 13 http://diveintohtml5.org/
  14. 14 http://www.w3.org/TR/html-design-principles/#evolution-not-revolution
  15. 15 http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-article-element
  16. 16 http://www.peachpit.com/store/product.aspx?isbn=0321687299
  17. 17 http://www.peachpit.com/articles/article.aspx?p=1629150
  18. 18 http://diveintohtml5.org/semantics.html#header-element
  19. 19 http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-header-element
  20. 20 http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-header-element
  21. 21 http://www.456bereastreet.com/archive/200911/headings_and_document_structure_conclusions/
  22. 22 http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#headings-and-sections
  23. 23 http://gsnedders.html5.org/outliner/
  24. 24 http://reference.sitepoint.com/css/formattingcontext
  25. 25 http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html
  26. 26 http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html
  27. 27 http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#sectioning-content-0
  28. 28 http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#forms
  29. 29 http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#embedded-content-1
  30. 30 http://diveintohtml5.org/
  31. 31 http://www.smashingmagazine.com/2010/09/23/html5-the-facts-and-the-myths/
  32. 32 http://www.smashingmagazine.com/2010/05/18/html5-and-flash-why-its-not-a-war-and-why-flash-wont-die/
  33. 33 http://www.smashingmagazine.com/2009/08/04/designing-a-html-5-layout-from-scratch/
  34. 34 http://www.smashingmagazine.com/2009/07/16/html5-and-the-future-of-the-web/

↑ Back to top Tweet itShare on Facebook

Louis Lazaris is a freelance web developer and author based in Toronto, Canada. He blogs about front-end code on Impressive Webs and curates Web Tools Weekly, a weekly newsletter for front-end developers.

  1. 1

    Thank you for the walk-through. HTML5 will not doubt have a huge impact on web development across all platforms and devices.

  2. 2

    Thanks, useful article and will hopefully get more of us into HTML5!

  3. 3

    Love the article, but wouldn’t recommend the book so disappointing, not really a ‘book’ and hardly scratches the surface.

  4. 4

    Nice info. You can find most of the HTML5 details in Jeremy Keith’s HTML5 for Web Designers – a fun book to read – a pleasant experience.

  5. 5

    Good article, the new organization/separation is nice, but I’m more excited for the video/audio tags

  6. 6

    Nice recap though I still don’t like the idea of wrapping each comment in an article tag. Even though you can syndicate each separate comment, without context a comment usually loses most of its meaning.

  7. 7

    the Jeremy Keith’s book is great , it gives you an easy overview on the HTML5 specs and functionality. I attended a Google’s conference on HTML5 a couple of days ago and you can find all the “slide” at the speaker’s blog @ http://www.monocubed.com , and a great resource could be the A List Apart contest on 10kb Apps.
    Take a look and thanks for the article.

  8. 8

    “which replace semantically meaningless ”

    Div meaning division of a page….the div tag hasn’t been replaced. That’s like saying when we moved from table based layouts to div based layouts that the table tag had been replaced.

    Other than that not a bad article

  9. 9

    Nesting article tags is new to me, more something you would do by exception rather then by rule. Wrap anything you might put in a feed, in an article tag.

    Still wondering how the Search Engines will manage the transition from xhtml to the html5 Content Models. Any news from the SEO front?

  10. 10

    I borrowed this book from a friend this week. Just got to Chapter 3 where the author speaks about plug-ins. Referred to Flash as being “closed” … sigh. Simply not true.

    Besides that bit of misinformation, seems like a good overview so far.

  11. 11

    Good read and well explained!
    Cant wait to get stuck into HTML5.. :)

  12. 12

    Also would like to know this – how does Google deal with multiple H1’s for example?

  13. 13

    I don’t see why the element is said to be semantically meaningless. stands for division. Then why are the or or etc. tags not semantically meaningless as well?

    Also in the vs debate we mix meaning and structure.

  14. 14

    You’re right, the wording of that is too all-encompassing. I meant the divs would be replaced in certain contexts. I’ll adjust that. Thanks.

  15. 15

    Nice read, you explain very well the basis like “article”, “section”, “footer” and “header”…

    But now, what about special DOM elements like “video”, “canvas”, “geolocalisation”, etc. with Internet Explorer 7 and 8? Is it compatible with theses “BROWSERS” ? If not, more than 70% of visitors will not be able to see HTML5 websites, or web apps correctly…

  16. 16

    Now if only MSIE would allow HTML5 elements to be styleable…
    But thx to HTML5Boilerplate with a little javascript-hack this can be done.

  17. 17

    The DIV is meaningless because the tag itself does not describe the content in any way. A DIV could wrap a header, a footer, a sidebar, a testimonial, a contact form — it could theoretically be anything. The section and article elements are not overly specific, but they are an improvement over DIV.

    But regarding “section” elements: After writing this article, I saw this article by Jeremy Keith and this piece on HTML5 doctor that admit some problems with “section” elements. It could be that the “section” element could be suffering from the same problem as DIVs.

    (Your comment’s tags got lost, too, so I’m not totally sure which ones you were referencing — just guessing.)

  18. 18

    I am looking forward to read an article called: “Learning to love Flash”
    Really necessary.

  19. 19

    Mark Petherbridge

    November 10, 2010 7:54 am

    lurve it :)

  20. 20

    Thanks for clearing up a few things Louis (I think!). I must say though I still feel that HTML5 was a missed opportunity. As builders of the web we’re all striving for solid semantics right? Well, what helps is a set of black and white rules, whereas too many new HTML5 tags are open to personal interpretation.

  21. 21

    Which HTML5-book do you people recommend for an HTML-developer?

  22. 22

    To be precise, on pg. 23 Keith says:

    But these technologies are not open. They are not created by the community. They are under the control of individual companies.

    I don’t think that’s a false statement.

  23. 23

    True, it’s too subjective. Just imagine working on a website of somebody who thinks a bit differently then you do.

  24. 24

    I fear that HTML5 will quickly be deemed convoluted and prone to crazy coding practices if it’s use can’t be clearly and simply indicated. I applaud your ability to keep this focused and quick. This is the best read on using Section and Articles in HTML5. Thus far, I have had a very hard understanding when and how to appropriately use these. HTML5 really demands graduating to a more sophisticated utilization of HTML.

  25. 25

    whatever ….till we are browser depended!!!! will take time to be supported.

  26. 26

    Out of curious, when do you believe it we’ll be able to use HTML 5 on our websites. I’ve been itching to play around with it on a few personal projects of my own but don’t due to fear of cross-browser compatibility.

  27. 27

    Good article Louis. I have two problems with the somewhat newish HTML5 tags. The first being, we were all trying to streamline our code and get as little as possible in the markup to do the job. Now we are cluttering up the page again with tags like hgroup, article, section and whatever. Not that big of a deal since you can replace a div with those, but you are adding more tags in certain areas.

    My second problem is the actual usage of these tags. Everyone knows when to use a ‘p’, ‘ul’, or what-not, but the “can” or “you could” use this tag for this, but “not necessarily” that bothers me. I want clearly defined tag usage so I know EXACTLY when and where to put them.

  28. 28

    It depends what you mean by that. You should start by reading this article:

    HTML5: The Facts And The Myths

    You can’t use every feature and technology, but you can use a lot of the basics like semantic elements. Also, some stuff is lumped in under the “HTML5″ label, but it’s not technically HTML5, so again, it depends on what you mean.

  29. 29

    I agree, those are problems. For example, if you replace 5 DIVs with 5 article or section tags, that’s automatically adding a few extra bytes to your HTML, simply because the word “section” is longer than the word “div”. Of course, as many have pointed out, DIVs are not obsolete, they are just going to be used less frequently.

    But remember that some things in the spec could still change, so we’ll have to see what happens.

  30. 30

    Nice article.

    But in your first Figure, explaining Articles – the POST article have in it, as there is not footer, no problem.

    But, in comments section, you have placed a inside . Why its not ? Isn’t it appropriate to place rather than there ?

    To be fair, I’m still confused :(

  31. 31

    Great article, but why must every commentator use the blog and syndication analogies to explain the subtleties of “article” and “section” when the vast majority of websites do not fit into this conceptual model? More real life examples would be very helpful.

  32. 32

    I agree. Almost every example I have seen deals with a blog. I want to know exactly how to use them in a typical static informational site. When and where do I use the ‘aside’ tag for example? It used to say that it wasn’t for a sidebar, but the rule has changed so that it can. I really hate the confusion of “you could” use it here. No, tell me “exactly” where to use it.

  33. 33

    Nice work. I say a good start for studying Html5.

  34. 34

    IE9 Beta allows the elements to be styleable, but you’re right, that is a bummer for previous versions.

    CORRECTION: the latest version of the Platform Preview supports the semantic elements, but AFAIK it’s not yet in IE9 Beta.

  35. 35

    I still don’t see the point. Will “article” or “section” tags help SEO or something? How is it improving anything?

  36. 36

    Still don’t understand what the use of header if we are using it multiple times on the page and sections?

    “A header element is intended to usually contain the section’s heading (an h1–h6 element or an hgroup element), but this is not required. The header element can also be used to wrap a section’s table of contents, a search form, or any relevant logos.” (http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-header-element)

    We need to specify IDs to access it, same with article and sections. and the worst part is IE 6,7,8 doesn’t support html5. I can’t design site only for specific users if the majority is of IE.

  37. 37

    DO u mean will be used only in blog sites?

  38. 38

    are people really using HTML5? [i mean i only saw video and canvas tag in most websites]. correct me if i am wrong.

  39. 39

    It’s not ready yet. multiple H1’s just an idea and browser (not sure with google) still doesn’t implemented (yet). if you use HTML5 today, you should take care for an old way (h1, h2, h3, …).

  40. 40

    Jeremy, I couldn’t agree with you more. Back when I was in school, I hated it when teachers would give an assignment that (presumably) had right and wrong answers, yet were “open to interpretation.” Some teachers insisted on saying things such as, “you could do that…” or “if that’s what you think you should do…” Although I am “a creative type,” I still like to know the boundaries I have to stay in, and HTML5 seems to have some very gray areas.

  41. 41

    To put it briefly: Those new tags make things portable (i.e. easy to move) and syndicatable (i.e. easy to feed to another source).

    This way, content can be taken from one page, and moved to another (or fed into another dynamically) and it will not disrupt the structure of the receiving page. Of course, the receiving page would be best suited to this if it used the new HTML5 structure, so I guess these benefits are still a ways off.

    I think the benefits to using section and article elements could be a topic of their own. I’ll get on that…. :)

  42. 42

    I would like to point out that multiple h1 tags in the same document is already perfectly valid. The html spec does not say you can not do this, in fact it says that most people consider it acceptable. You can read this for yourself at http://www.w3.org/TR/html4/struct/global.html#h-7.5.5 There is nothing wrong with doing this as long as it follows a logical hierarchy and properly reflects the structure of your document. What you should not do is skip levels as it does not follow any logical structure.

  43. 43

    Great article but wouldn’t recommend this book. NOTHING in it.

  44. 44

    Had the opportunity to listen to Jeremy Keith at drupalcon 2010 in copenhagen, and I would recomend this book to anyone, it’s great ground to start your html5 tour.

  45. 45

    Nice, but still not ready to start with, but I think it will be soon.
    vikandesign.se still running on html & php :)

  46. 46

    Introducing HTML5 by Bruce Lawson & Remy Sharp is slightly more developer focused IMHO.

  47. 47

    Oh, veo que ha desaparecido mi educado comentario elogiando a flash.
    Muy propio de regímenes totalitarios.
    ¡Me voy antes de que me deportéis.!

  48. 48

    Nice read; thanks for sharing.

    When it comes to semantics and HTML5 I especially love the microdata. I try to use HTML5 to my new projects, but the need of javascript in ‘ lte IE8 ‘ is a problem. Customers sometimes still -sigh- request a IE6 compatible website. What is your opinion in this one? Do you use HTML5 already in your projects? If so, do you offer a working alternative for IE users without JS enabled ( for example: (X)HTML4 warning page with JS redirect to (X)HTML5 version ) ?

  49. 49

    Using the html5 doctype is no problem. Using html5 coding standards and its new tags on an industry website is irresponsible. There is no telling how IE browsers without javascript support will react to your new tags, screenreaders are coded to the current standards – not 2020 standards – and Google still advises you to not use multiple h1’s on a page.

    Warning: For some reason this page uses highly experimental non-standard mark-up. Use a browser from 2010 to fully access this content. Caution: Since the coding practices used by this page creator are still in development phase, anything as short as a year, might completely change the semantics of tags and marked-up content on this page. Happy HTML5! Oh.. And we added an AJAX contact form (AJAX! AJAX! AJAX!) so to contact us, you need javascript support or you write us a letter. To proceed to the content click this link: http://ishtml5readyyet.com/

    HTML5: Let’s design a standard to the bell curve of the internet… Be honest guys and gals, why don’t we just call it a new version of WordPress with some proprietary tags?

  50. 50

    Definitely doesn’t help with SEO right now, but it very well might in the future.

    The big benefit for semantics (and thus for machine understanding, that includes searchbots) will be to have sections and relations. Like a Div is a Divider that can be used to group page elements, so is a Section a more semantic variant of grouping elements together: a heading, subheadings, paragraph text and an aside (with sources, media, related pages).

    The problem with HTML4 is that this grouping isn’t fully possible on a semantic level, because a Div is rather meaningless. There is also no other way in HTML4 to create a document outline without using headings. In HTML5 you can use a Hgroup to create a single document node, whereas in HTML4 each heading creates it’s own node.

    For lots more clearly explained differences between HTML4 and HTML5 and the benefits HTML5 gives in creating an improved, more meaningful document outline read: http://diveintohtml5.org/semantics.html

  51. 51

    Adding new tags to improve the document outline and further the semantics of the document structure, so it becomes more machine readable and portable is a very good thing.

    “Streamlining” would not be the verb I’d use when you don’t use these tags, because it adds to your mark-up.

    You will have a complete spec when it gets released, there is uncertainty with its users now, because the very tag definitions are still hazy. Only after HTML5 becomes a standards, can a webdev know what and how to use these new tags to the letter.

    Since these new tags are mostly to mark-up document outline, and the older tags are used to mark-up content: or these new tags give meaning to document structure, the old tags give meaning to the content – you will always operate on a more abstract level. What defines document structure is very personal to the document author. What defines document content isn’t. That is why these new tags are kept somewhat ambiguous: to be free to outline your document and give meaning to its structure.

    Also as soon as WordPress HTML5 comes out, even these document outline methods will be heavily standardized.

  52. 52

    Red herring when Google (the lifeblood of nearly every commercial website) says not to make excessive use of multiple h1 headings on a page.

    You’ll have a hard time really defending putting more than two h1 headings on page. W3C also says you can use tables to arrange data, but coding a navigation inside a table (perfectly allowed) or putting a form inside a table (perfectly allowed) isn’t something you’d want to find widespread on the internet, count as an argument for using tables for layout, or teach to a new webdeveloper.

    Speaking of the devil, Matt Cutts, Engineer at Google: http://www.youtube.com/watch?v=GIn5qJKU8VM More than one H1 on a page: good or bad?

  53. 53

    Nice writeup, not read the whole book but I did notice it in the iBooks Store and downloaded a Sample.

    Thanks for the share!

  54. 54

    Ow, and for future SEO impact, look at what Google is doing right now with semantics on content blocks, such as a heading followed by a list: http://www.seobythesea.com/?p=3824 (Google Defines Semantic Closeness as a Ranking Signal). And imagine what it can do with the semantically improved document outline of HTML5.

  55. 55

    nice article man…..hope more an more

  56. 56

    Which i am also looking forward to but with HTML5 looking like it is being held up for a few years i can’t see my company taking it on till it’s ready.

  57. 57

    testing the form

  58. 58

    Related to this- I fail to see how “section” is any more or less semantic than “division,” which “div” is short for. When thought of as “an article of clothing,” the same can be said of “article.”

  59. 59

    Nice one! I have been waiting HTML 5 for a long time, it’s good to see that things moving the right way! :)

  60. 60

    Straydog Branding

    November 12, 2010 8:30 am

    This book nevertheless is a must read for anyone new to HTML5 and wanting to get a taste of what it is, what it offers, and how it can be used.

  61. 61

    I just put down Introducing HTML5 by Bruce Lawson to read this article and it just retold everything I read so far. And that’s just pretty cool.

  62. 62

    Interesting post. I have added it to the “HTML5 for Enterprise and Mobile applications” page (http://www.facebook.com/pages/Html5-for-Enterprise-and-Mobile-applications/175012219177552?v=wall)

  63. 63

    I think that while the section and article tags may have similar uses, the content contained within each on respectively can be very different. After looking at the spec description it makes sense for article to me used for content such as this, whereas section would not be used for content “posts” such as this article, instead finding its way into situations like upcoming events and announcements. Also, it makes sense to have articles within sections, as in a feed previewer which is the section and the previews are the articles, and where sections are withing articles, such as chapters within a larger article.

    I understand the more than one h1 tag sounds like too many, but even listening to the guy from Google talk about using them, be leaves room for the tags, while still saying “not too many.” I take this to suggest that a new h1 is appropriate for the beginning of every parent article or section.

  64. 64

    HTML5 is just a big failure in the design industry. no one will use it. unless ie6 dissappear for ever, but thats no going to happen in a lonnnnnnng time.

  65. 65

    semantics tag was a bad idea, imho.

  66. 66

    This is a great article. Thanks for simplifying the basics of html5.

  67. 67

    This book nevertheless is a must read for anyone new to HTML5 and wanting to get a taste of what it is, what it offers, and how it can be used.

  68. 68

    Great post Louis, I think this highlights really well the learning curve that developers embracing HTML5 have to go through. The brief rule that we have picked up on are that articles can be syndicated, sections really should have a heading and that divs are fine if the other two do not fit, but these are usually just for styling purposes, in our experience. The books and sites you have referenced (as well as the spec) have been a great resource and I encourage other developers to read the spec too, although not always the easiest to digest, why not?

  69. 69

    i agree you 100%, ie6 is the black sheep.

  70. 70

    I am learning to love HTML5, but it’s a big change over for me.

    Thanks for posting.

    -Jessica Boblooch

  71. 71

    What I love the most about HTML5 is the great support it has in terms of SEO, just look at the ‘hgroup’ tag that wraps multiple Heading tags and make it one but still keep the hierarchy of the heading tags… if you go into more detail you will also notice that the ‘em’, ‘i’, ‘b’, ‘strong’, etc. have different characteristically when it comes to SEO (machine/robot reading) then they use to have.

    What’s also great is the video and audio embedding capabilities (it’s a shame that mp4 isn’t supported by most browsers due to legalities that might be happening in the future), but on a positive not, Firefox 4 will be adding Open GL support which will make it possible to run games engines through a browser, now that’s impressive.

    I’m hoping that in the not so distant future HTML5 will KILL Flash on the web, in my opinion open source will always be a million times better then a paid service, and the support will always be better.

  72. 72
  73. 73

    Great article!
    It helped me to better understand some of the new elements HTML5 offers us.


↑ Back to top