The devil in the details

September 15th, 2009

Looking through the list of hiccups highlighted by the HTML5 Super Friends and my own personal tally, things are progressing at a nice clip with HTML5.

• The pubdate attribute has been removed from the article element and shifted to a nested time element instead.
• The content model for the footer element has been changed to match author expectations—that’s a biggie.

That still leaves a few issues:

• The confusion between section and article that I’ve been researching.
• The restrictive content model of the small element not matching that element’s updated semantics.
• The time element not allowing month or year dates i.e. YYYY-MM or YYYY.

Then there’s the issue with details and figure. The insistence on recycling the legend element leads to all sorts of problems with browsers today, as described by Remy.

This has been an ongoing discussion in the HTML5 IRC channel and on the HTML5 mailing lists. It flared up again recently and I fired off an email to the HTML Working Group yesterday:

I understand the aversion to introducing a new element … but I don’t understand why legend is being treated as the only possible existing element to recycle.

For example, dt and dd are being recycled in the new context of dialog so they no longer mean “definition title” and “definition description”. Now they can also mean (presumably) “dialog title” and “dialog description”.

If those elements are already being recycled, why not apply the same thinking to details so that dt and dd could also mean “details title” and “details description”?

To be honest, I was just spouting that out without really thinking. How about… something like—not this, obviously, not this, but what if…

So imagine my surprise when Hixie responded:

That’s not a bad idea actually. Ok, done.

Wow. Okay.

While I was at it, I also did this for figure

Alright. Makes sense, I suppose …although the names of the elements dt and dd aren’t quite as intuitive in the context of figure as they are in details.

and removed dialog from the spec altogether.

Er …okay. Seems somewhat unrelated to the issue at hand but I guess that the dialog element has been a point of contention. It’s mentioned by the HTML5 Super Friends so that’s another one that we can tick off the list.

So how should we mark up conversations now? Here’s what the spec now suggests:

Authors who need to mark the speaker for styling purposes are encouraged to use span or b.

Um… what? The b element? Really? You have got to be kidding.

Excuse me while I channel Carrie’s mother, but I can predict exactly how authors are going to react to this advice: They’re all going to laugh at you!

@gcarothers: Jaw, floor, WHAT?! http://bit.ly/48Bhta Why in the world would #html5 suggest using <b> tags to markup names?

@akamike: There are more appropriate tags than <b> for marking up names in conversations. “The b element should be used as a last resort…” #html5

@cssquirrel: Well, if the <p><b> recommendations for dialog in #html5 persist for a week, I know what I’m drawing.

Perhaps now would be a good time to mention that the cite element is also listed by the HTML5 Super Friends. Call me crazy but I think it might just be the right element for marking up the person being cited.

<p> <cite>Costello</cite>: <q>Who's playing first?</q> </p>
<p> <cite>Abbott</cite>: <q>That's right.</q> </p>

9:28pm

Tagged with html5 markup standards html semantics whatwg w3c

Illustrations

Thanks to the magic of machine tags, you can illustrate this post by tagging a picture on Flickr with:

Related

Links

Find links I've tagged with html5, markup, standards, html, semantics, whatwg, w3c, etc.

Photos