dl: what is it good for?

Saturday 1st August

After almost a year of fairly sporadic blogging, an argument has finally arisen.

Quite a minor one, admittedly — at the last count, my article on implementing a progress bar has elicited only 3 responses of which I’m aware. They all focused on the use of the humble dl:

Unsurprisingly, it’s that last response that I want to comment on in further detail.

Criticism

First, Ross’s reaction is related to his aim of improving the quality of web-based articles, a mission I whole-heartedly endorse. His article states, amongst other guidelines, that commenters should:

be nice!

and commentary should involve:

no personal attacks

It’s somewhat ironic, therefore, that Ross’s initial criticism took the form of a 2-word description of the article:

’Tis shite

To give Ross some credit, he’s since amended the description to read:

Should not be a definition list. Those poor things always get misused.

which, at least, gives me something to work with. I’m not sure if the delicious tagging, despite being an inventive application, is the best way to achieve those aforementioned aims, but I’ll let that go for the moment and concentrate on the matter in hand.

Is this a ‘definition’ I see before me?

This argument is a specific case of ‘You shouldn’t use <foo> for that; use <bar> instead’. I’m one of the first to get all pedantic and standards-obsessed over use of appropriate HTML elements: I’m one of few people who would worry about (or even consider) whether using an unordered list for a series of breadcrumbs isn’t quite as good as using an ordered one. But I recognise that there’s a subjective element to choosing the ‘right’ … element. Marking up your content is quite a craft.

I first came across ‘creative’ use of the dl element in Dan Cederholm’s excellent book, Bulletproof Web Design. Dan uses definition lists to markup a basic photo gallery, and justifies that structure with reference to the W3 spec. That spec suggests that definition lists should not be strictly limited to describing the basic glossary type of information that is their most obvious use case. HTML5 goes even further, clearly stating that:

Name-value groups may be terms and definitions, metadata topics and values, or any other groups of name-value data.

One of the several examples in that section is the following:

<dl>
 <dt> Last modified time </dt>
 <dd> 2004-12-23T23:33Z </dd>
 <dt> Recommended update interval </dt>
 <dd> 60s </dd>
 <dt> Authors </dt>
 <dt> Editors </dt>
 <dd> Robert Rothman </dd>
 <dd> Daniel Jackson </dd>
</dl>

I don’t know if this is just me, but "Recommended update interval: 60s" feels very much like the "Completed: 23%" content I was marking up in the first place. So, yes, I’d argue that a dl is certainly an appropriate, and probably the most appropriate, element to use in this case.

Structure versus display

The reason I think this type of markup feels ‘wrong’ to people is quite simple: the visual rendering of progress as a ‘bar’ transforms it into something that looks very different from a glossary listing. However, that’s the very nature, and power, of the HTML/CSS split. Without the styling, that task status is displayed as a standard listing, and is readable and understandable. With some appropriate CSS, that information can be rendered in a totally different way, but it remains the same information.

Ultimately, I’d love a response from Ross to take the following form:

Ross, the ball’s in your court :-)


Comments

Sun 2 Aug 2009 00:08

Ross Bruniges

Ross Bruniges said:

Heya man.

First up — you’re 100% correct. My review of your article was totally against my ethos of commenting and for that I wholesomely apologise. As you've seen I've now changed it to be more constructive and hopefully I can add to it here.

So yeah, as you've seen from your intensive research on the matter these arguments have been going on for a while. Definition lists seem to provide a solution in which we can avoid using divs and spans and use an actual HTML element and the spec contradicts itself rather on the actual correct use-case for it. It’s also interesting to note that the spec for HTML4 and HTML5 vary slightly in the fact that Ian Hickson has explicitly 'banned' the use of DL's for dialog (something the HTML4 spec suggested as an OK usage) — I believe this further highlights this elements plight!

Anyways, back to the progress bar.

My feeling that in definition lists dt should define it’s dd. In this content the description for progress should be "the percentage of {var} that has been loaded".

Also the definition list on it’s own provides no feedback to what it actually is — all we have are a couple of definitions with no explanation that they are progress bars. Visually it might be fairly easy to assume this information but we all know what happens when you assume things and also not everyone will have a visual browser.

The best article I can find about definition lists and there misuse is http://24ways.org/2007/my-other-christmas-present-is-a-definition-list (well worth a read).

Mon 3 Aug 2009 04:10

Five Minute Argument

Five Minute Argument said:

Many thanks for taking the time to respond, Ross; I really do appreciate it.

In terms of the specifics of the progress bar, I'll just say:

a) I’d still like to think that, in terms of content representing 'percentage of task complete', regardless of how that’s presented, a definition list is about the 'most semantic' option we currently have available. If not, what’s better?

b) I would definitely recommend — as you suggest — that authors use a heading of some sort (or, possibly, a title attribute on the list, depending on context) to describe what the progress actually represents.

c) In terms of HTML5, the 'progress' element is likely to make this specific discussion obsolete, anyway!

In general, I think that dl’s still have their place for data description; many of the commenters on the 24 ways article you referenced agree. Name/value pairs really have no better alternative, more semantic element, as far as I can tell. Unless you have a good suggestion, of course. Otherwise, we may just have to agree to disagree!

Leave a comment