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
