{"id":4057,"date":"2010-11-10T13:53:02","date_gmt":"2010-11-10T13:53:02","guid":{"rendered":"http:\/\/www.lamorbidamacchina.com\/ssssimone\/?p=4057"},"modified":"2010-11-10T13:53:02","modified_gmt":"2010-11-10T13:53:02","slug":"4057","status":"publish","type":"post","link":"https:\/\/www.lamorbidamacchina.com\/ssssimone\/4057\/","title":{"rendered":""},"content":{"rendered":"\n\n
\n
\"Advertisement
\"<\/a> \"<\/a> \"<\/a><\/div>\n<\/td>\n<\/tr>\n<\/table>\n

It seems that new resources and articles for teaching and promoting HTML5 are popping up almost daily. We\u2019ve been given HTML5 templates in the form of the HTML5 boilerplate<\/a> and HTML5 Reset<\/a> (although they both go beyond just HTML5 stuff). We\u2019ve got a plethora of books<\/a> to choose from that cover HTML5 and its related technologies. We\u2019ve got shivs<\/a>, galleries<\/a>, and a physician<\/a> to help heal your HTML5 maladies. And don\u2019t forget the official spec<\/a>.<\/p>\n

From my own vantage point \u2014 aside from a few disputes<\/a> about what the term \u201cHTML5\u2033 should and shouldn\u2019t mean \u2014 the web design and development community has for the most part embraced all the new technologies and semantics with a positive attitude.<\/p>\n

\"4764451727<\/a>
Flickr Photo by Jeremy Keith<\/a><\/em><\/p>\n

While it\u2019s 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\u2019m personally in the process of gaining a better understanding of the subtleties of HTML5\u2032s various new features<\/strong>, 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.<\/p>\n

The Good (and Easy) Parts<\/h3>\n

The good stuff in HTML5 has been discussed pretty solidly in a number of sources including books by Bruce Lawson<\/a>, Jeremy Keith<\/a>, and Mark Pilgrim<\/a>, 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).<\/p>\n

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

An <article> Isn\u2019t Just an Article<\/h3>\n

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

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

Let\u2019s consider a blog post as an example, which is the same example used in the spec<\/a>. Naturally, we would think a blog post marked up in HTML5 would look something like this:<\/p>\n

 <article> <h1>Title of Post<\/h1> <p>Content of post...<\/p> <p>Content of post...<\/p> <\/article> <section> <section> <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> <\/section> <\/section> <\/pre>\n
For brevity, I\u2019ve left out some of the other HTML5 tags that might go into such an example. In this example, the <article><\/code> tags wrap the entire article, then the \u201csection\u201d below it wraps all the comments, each of which is in its own \u201csection\u201d element.<\/p>\n
It would not be invalid or wrong to structure a blog post like this. But according to the way <article><\/code> is described in the spec, the <article><\/code> element should wrap the entire article and the comments<\/em>. Additionally, each comment itself could be wrapped in <article><\/code> tags that are nested within the main <article><\/code> tag.<\/p>\n
Below is a screen grab from the spec, with <article><\/code> tags indicated:<\/p>\n
\"Html5-articles
Article tags can be nested inside article tags \u2014 a concept that seems confusing at first glance.<\/em><\/p>\n
So, an <article><\/code> element can have other <article><\/code> elements nested inside it, thus complicating how we naturally view the word \u201carticle\u201d. Bruce Lawson, co-author of Introducing HTML5<\/a>, attempts to clear up the confusion in this interview<\/a>:<\/p>\n
\n
\u201cThink of <article><\/code> not in terms of print, like \u201cnewspaper article\u201d but as a discrete entity like \u201carticle of clothing\u201d that is complete in itself, but can also mix with other articles to make a wider ensemble.\u201d<\/p>\n
\u2014 Bruce Lawson<\/p>\n<\/blockquote>\n
So keep in mind that you can nest <article><\/code> elements and an <article><\/code> element can contain more than just article content. Bruce\u2019s explanation above is very good and is the kind of HTML5 education that\u2019s needed to help us understand how these new elements can be used.<\/p>\n
Section or Article?<\/h3>\n
Probably one of the most confusing things to figure out when creating an HTML5 layout is whether or not to use <article><\/code> or <section><\/code>. As I write this sentence, I can honestly say I don\u2019t know the difference without actually looking up what the spec says or referencing one of my HTML5 books. But slowly it\u2019s becoming more clear. I think Jeremy Keith defines <article><\/code> best on page 67 of HTML5 for Web Designers<\/em>:<\/p>\n
\n
\u201cThe article<\/code> element is [a] specialized kind of section<\/code>. Use it for self-contained related content\u2026 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<\/code> is probably the right element to use.\u201d<\/p>\n
\u2014 Jeremy Keith, HTML5 for Web Designers<\/em><\/p>\n<\/blockquote>\n
Keith\u2019s explanation helps a lot, but then he goes on to explain that the difference between <article><\/code> and <section><\/code> is quite small, and it\u2019s 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<\/strong>.<\/p>\n
As a result, you might wonder why we have both. The main difference is that the <article><\/code> element is designed for syndication, whereas the <section><\/code> 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.<\/p>\n
Headers and Footers (Plural!)<\/h3>\n
Two other elements introduced in HTML5 are the <header><\/code> and <footer><\/code> elements. On the surface, these seem pretty straightforward. For years we\u2019ve marking up our website headers and footers with <div id="header"><\/code>, <div id="footer"><\/code> or similar. This is great for DOM manipulation and styling, because we can target these elements directly. But they mean nothing semantically.<\/p>\n
\n
\u201cThe div<\/code> element has no defined semantics, and the id<\/code> attribute has no defined semantics. (User agents are not allowed to infer any meaning from the value of the id<\/code> attribute.)\u201d<\/p>\n
\u2014 Mark Pilgrim, Dive Into HTML5<\/em><\/a><\/p>\n<\/blockquote>\n
HTML5\u2032s introduction of <header><\/code> and <footer><\/code> 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><\/code> and one <footer><\/code> to each of their pages, this would be perfectly valid HTML5. But these new elements are not just limited to use as a \u201cwebsite header\u201d and \u201cwebsite footer\u201d<\/strong>.<\/p>\n
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.<\/p>\n
But the same page might also include multiple <section><\/code> 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:<\/p>\n
\n
\u201cA header<\/code> will usually appear at the top of a document or section, but it doesn\u2019t have to. It is defined by its content\u2026 rather than its position.\u201d<\/p>\n
\u201cLike the header<\/code> element, footer<\/code> sounds like it\u2019s a description of position, but as with header<\/code>, this isn\u2019t the case.\u201d<\/p>\n
\u2014 Jeremy Keith, HTML5 for Web Designers<\/em><\/p>\n<\/blockquote>\n
And the spec adds to Keith\u2019s clarification by noting:<\/a><\/p>\n
\n
 \u201cThe header element is not sectioning content; it doesn\u2019t introduce a new section.\u201d<\/p>\n
\u2014 The header element in the HTML5 specification<\/a><\/p>\n<\/blockquote>\n
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<\/strong>.<\/p>\n
Headings Down A Different Path<\/h3>\n
Prior to HTML5, heading tags (<h1><\/code> through <h6><\/code>) were pretty easy to understand. Over the years, some best practices<\/a> have been adopted in order to improve semantics, SEO, and accessibility. Generally, we\u2019ve become accustomed to including a single <h1><\/code> element on each page, with the other heading elements following sequentially without gaps (although sometimes it would be necessary to reverse the order).<\/p>\n
With the introduction of HTML5, to use the new structural elements we need to rethink the way we view the structure of our pages.<\/strong><\/p>\n
Here are some things to note about the changes in heading\/document structure in HTML5<\/p>\n