[whatwg] Thoughts on HTML 5

[html at nczonline.net]

I had posted this on my personal blog: http://nczonline.net/blog/2008/2/28/thoughts_on_html_5. Ian requested I join the mailing list to continue the discussion, so here it is:

------------------------------------
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).
-----------------------------------------

Lachlan had commented that "irrelevant" could be changed dynamically to indicate parts of an application that may be relevant only during particular points in time. I don't see how this is any different from hiding content that isn't necessary.

Also "contenteditable" doesn't solve my issue with rich text editing. It solves the ability to do it, but not a straightforward way to do it in the context of a form and submit it back to the server without some intermediary code. My point is that there should be a way to submit rich text in a form by default, without needing to write extra JavaScript code.


-Nicholas