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 boilerplate and HTML5 Reset (although they both go beyond just HTML5 stuff). We’ve got a plethora of books to choose from that cover HTML5 and its related technologies. We’ve got shivs, galleries, and a physician to help heal your HTML5 maladies. And don’t forget the official spec.
From my own vantage point — aside from a few disputes 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. Flickr Photo by Jeremy Keith
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.
[Editor's note: A must-have for professional Web designers and developers: The Printed Smashing Books Bundle is full of practical insight for your daily work. Get the bundle right away!]
The Good (and Easy) Parts
The good stuff in HTML5 has been discussed pretty solidly in a number of sources including books by Bruce Lawson, Jeremy Keith, and Mark Pilgrim, 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 principles 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 Isn’t Just an Article
Among the additions to the semantic elements are the new and tags, which will replace certain instances of semantically meaningless
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 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 spec. Naturally, we would think a blog post marked up in HTML5 would look something like this:
For brevity, I’ve left out some of the other HTML5 tags that might go into such an example. In this example, the 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 is described in the spec, the element should wrap the entire article and the comments. Additionally, each comment itself could be wrapped in tags that are nested within the main tag.
Below is a screen grab from the spec, with tags indicated: Article tags can be nested inside article tags — a concept that seems confusing at first glance.
So, an element can have other elements nested inside it, thus complicating how we naturally view the word “article”. Bruce Lawson, co-author of Introducing HTML5, attempts to clear up the confusion in this interview:
“Think of 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 elements and an 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 or . 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 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 and 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 element is designed for syndication, whereas the 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 and
No comments:
Post a Comment