I’ve just finished taking a look at the working draft of HTML 5 and thought I’d share my thoughts. Clearly, HTML 5 is meant as an evolution of HTML 4, which has both its good and bad points. Accordingly, there are both good and bad parts of the specification. My thoughts are as follows:

• I almost laughed when I saw the irrelevant attribute. First, because that’s a word that web developers throw around a lot and second because I can’t imagine ever using it. The spec says, “When specified on an element, it indicates that the element is not yet, or is no longer, relevant. User agents should not render elements that have the irrelevant attribute specified.” If it’s not relevant, why is it in the page in the first place? Further, do you know how many people will spell this wrong 100 times before they spell it right? Unless there’s a deeper meaning or requirement behind this attribute, I think it’s just a waste of a section.
• The scoped attribute is a welcome addition to the <style/> element. Being able to apply styles to just a section of the page is something that I’ve personally struggled with mightily. I’m glad to see a logical solution.
• I’m not sure what the <section/> element offers over the <div/> element. I thought the purpose of the <div/> was to indicate a section of the page. If there’s not a clear distinction between these elements, I don’t see the need for a second one.
• I like the <nav/> element. It’s helpful in a number of ways to have an area marked as being for navigation. The accessibility implications alone are outstanding.
• I’m a bit unsure of the <article/> element. As with <section/>, it seems only vaguely different from <div/> and too focused on solving the question of what markup to use for a blog.
• The <aside/> element really pushes the boundaries of marking up literary devices. I’m not sure enough web developers know what an aside actually is. Short asides are typically indicated by parentheses and I don’t see any reason not to keep doing that (seriously). Any element that requires someone to ask an English teacher when it should be used is probably a bad idea.
• I understand the concept of the <dialog/> element but it’s named completely wrong. The point is to markup a conversation between two or more parties. The problem is that the word “dialog”, when in used in user interfaces, refers to small windows that can be interacted with. When I first read about this element, I assumed it was a way to indicate that part of the page is a dialog window outside of the normal flow of the document (which I thought was cool). After reading the rest, I was disappointed to find out that wasn’t the intent. I’d rename this element as <conversation/> or <discussion/> to avoid such misunderstandings.
• The ping attribute on the <a/> element is a stroke of pure genius. We’ve been left hacking solutions for click monitoring for way too long.
• The <dfn/> is another that stresses the understanding of grammatical structure for web developers. The intent is to designate the defining instance of a term, abberviation, or acronym. Does that make sense to you? If it did, give yourself one point; if it didn’t, don’t feel bad, most people won’t get it. Again, any element that leaves people scratching their heads probably isn’t necessary or useful.
• Speaking of confusing, I’ve read the section about the <meter/> element five times now and still have no idea what it’s used for.
• The <video/> and <audio/> elements bring some much-needed sanity to the embedding of media into web pages.
• The async attribute is a welcome addition to the <script/> element, allowing it to perform non-blocking code execution. Realistically, this is useful only for a small number of JavaScript files as there are often dependencies between JavaScript files.

The entire specification is insanely long and, interestingly, covers much more than just markup. It also covers related and unrelated DOM interfaces as well as additional JavaScript APIs. I think it’s heading in the right direction, but HTML 5 does miss some things that seem to be issues that should be addressed:

• I’d like to see some treatment of rich text input controls. Right now we all use a hack (an iframe in design mode) that has to be copied over into a form field to be submitted. It would be nice to have this handled natively and have reliable HTML formatting of that content (instead of the per-browser implementations we have now).
• I’d like to see a common attribute that can be used on any element to indicate information related to the element. I’m tired of fighting the custom attribute battle. The fact is that it’s a very common need to include extra data related to an element. I’d propose a “reldata” attribute (short for “related data”) be considered as an optional attribute on all elements. We then, as developers, could use that attribute as we see fit and the document would still validate (for people who care about such things).

So that’s my perspective on where things are with HTML 5. There’s a lot I didn’t cover, and I’d recommend that you read through the whole thing yourself and come to your own conclusions. Evolution is a difficult process, but at least it’s progress.

Disclaimer: Any viewpoints and opinions expressed in this article are those of Nicholas C. Zakas and do not, in any way, reflect those of my employer, my colleagues, Wrox Publishing, O'Reilly Publishing, or anyone else. I speak only for myself, not for them.