dl-dd-dt/sounds like stammering to me
Today, let's talk unsexy html5. One of the more commendable things the html5 group is doing right now is updating definitions of elements that caused confusion in the past. Rather than deprecating all these elements and introducing newer ones these elements have been given proper semantic meaning, clearing up most of the confusion surrounding them. At least, in theory.
Every language has its flaws. Yeah ... even html. I've blogged about the address element before, but other elements like <b> and <i> also experienced their fair share of controversy back in the days. Redefining these elements is fine, even at the cost of temporarily introducing unwanted or ambiguous semantic value (older code could never have been written with the newer definitions in mind). In some cases though, I strongly believe it would be better to simply rethink an element from scratch.
dl: definition list or description list?
The definition list (<dl>) was without a doubt one of the most confusing html elements out there. Though actually quite properly defined, its practical value was very limited. Unhappy with this situation many people kept coming back to it, trying to find proper uses for the element. The definition of "definition" became an almost theological debate, leading the definition list to be used as mark-up for forms and other strange, completely unrelated structures.
It's time to let go of all of that. The definition list is no more, long live the description list. While its name could still cause some confusion, the definition to go along with the element leaves little to the imagination. Here's what the w3c has to say about it:
quote The dl element represents an association list consisting of zero or more name-value groups (a description list). unquote
Important here is the use of "name-value" in the definition, broadening the use of the element significantly and making it a very suitable element for what I call the caption-detail structure. A very typical structure often seen in meta data and profile data.
If you'd like more practical information on the dl revamping, you can check the html5 doctor article.
why dl sucked in the first place
Thing is though, the biggest problem with the dl elements was never its poor practical use or strict definition, but its poor structure. It was originally devised as a list of definitions, a case where the list structure actually made sense. But even then, the fact that a unique couple of terms and definitions could only be determined based on order (since they lack a unique containing element) made it into a structural mess. Contrary to other html lists, there is no <li>-like element to speak of.
This structural weakness carries over to styling, something most people who've tried to properly style a dl should have experienced already. It's doable as long as the couples are displayed as a typical list, but try anything fancier and you're dead out of luck.
The new definition of the element further underlines its structural weakness. Should you use the dl for meta data, there is no proper way to add extra semantic value (classes like .author, .publishdate, .lastchanged, ...). Of course you could always add the class to the term and make it a rule that the following dds are included in the data, but that would go against 20 years of proper html and microformats structuring.
what it should be like
With the new description element, there's really no good reason to stick with the whole "list" concept. The dl element could function as a container for each couple, uniquely identifying one name-value group. The context of the element could (and should) determine whether the dl is part of a list or appears as a standalone element. Code speaks louder than words, so below a couple of examples of what I'm talking about.
Author metadata:
/* name-value as meta data */
<dl class="author">
<dt>author:</dt>
<dd>Niels Matthijs</dd>
</dl>
Full name data field in a profile:
/* name-value as profile data */
<dl class="fullname">
<dt>name:</dt>
<dd>Niels Matthijs</dd>
</dl>
Full name input field in a form:
/* name-value as input/form data */
<dl class="input fullname">
<dt>name:</dt>
<dd><input type="text" /></dd>
</dl>
conclusion
The name-value pair (dt-dd) of the dl element is one of the only html elements out there which is not defined by a unique parent. Even worse, it's current structure is effectively making it impossible to do just that. This is a big structural flaw with noticeable effects on styling and javascript. The new definition of the dl element is a lot better, but without structural change the element will remain a pain in the ass for years to come. Even worse, because the new definition is actually forcing us to use the element in more places. Let's hope the nice people of the w3c will take the time to fix that.
Comments
Laura
I encourage you to file a bug on the spec.
http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG&component=HTML5%20spec%20%28editor%3A%20Ian%20Hickson%29&priority=P3
Anders
I agree on that a structural change would certainly make it easier when it comes to styling. However, out of curiousity, it would be nice if you could provide an image of a certain style that is not doable with the current structure of a definition list.
One more thing: I can see that the Article info & Visitor stats in the sidebar aren't marked up as definition lists. Is that an example of where you felt the structure didn't allow you to achieve the desired looks?
Niels Matthijs
The stats on the article pages are old code, written back when the dl was still a pure definition list. As I never considered the name-value pairs as "definitions", I didn't use a dl. With the new definition (description list), this would indeed be a prime example for using the dl element. And I think it would be easy enough to style the current design, so no problems there.
I've made an example of a very simply layout which I think is not possible with the current proposal: http://www.onderhond.com/testpages/description-list.html There is no stable way to get the author information to the right when using the current spec, so that's a big problem.
I have been talking to html5doctor about this "problem", apparently the w3c considers it a css problem and not so much a html problem. Can't say I agree, but that's the status so far.
More info on why the structure of the dl element won't change
Anders
Thanks for the update! With CSS3 it is actually quite easy to solve your case.
dl {text-align: right;} dt:nth-of-type(odd), dd:nth-of-type(odd) {float: left;}
You could also cover for the case where you would have multiple authors to an article with the following selector: dd:nth-of-type(even) + dd {float: none;}
Niels Matthijs
So I've updated the example page with a third pair which should appear right below the right pair.
http://www.onderhond.com/testpages/description-list.html
While you managed to fix the first example, I'm not really happy with the method. You (ab)used to odd and even properties to target the needed elements, but when extra pairs are added the code above makes very little sense.
I had hoped that css3 would at least allow us more flexibility and control, making the code we write better at withstanding changes and updates. Not writing something quite complex to do a very simple thing, breaking the moment the circumstances change.
(and I'm sorry if I sound a little bitter, I do appreciate your solution, just not the kind of code I would like to use!)
Bobby Jack
Hi Niels,
Just to summarise the problem, as I see it:
DTs and DDs are associated by their adjacency. This is - in theory - just as 'soundly structural' as being associated by a common parent ...
... however, that association doesn't create any kind of containing block that can be styled using CSS.
From one perspective, adding a common parent element would just be duplication of the adjacency structure, solely for the purposes of 'CSS hookery'.
I'm not sure I like the idea of making all dl lists single-item containers only - how does one, for example, differentiate two separate groupings of several related meta data items?
There are other elements that suffer this problem, most notably label/input pairs. At a stretch, headings and their following paragraphs also suffer (although HTML5 helps).
Although I'm unsure of the syntax required, I wonder if there's a need to create a generated box using CSS alone. This has the potential to solve your problem (without changing markup structure/rules) and reduce the need for other existing cases of extraneous markup.
Niels Matthijs
In theory - maybe - but it still sounds like a pretty bad idea to me. html has always centered around "unique logical units" and two adjacent element simply don't form a single unit. You'll also need separate data retrieval algorithms (both for JS and crawlers) to get to the data. I'm sure some people won't mind, but it creates a precedent to other random constructions in the future.
Also, I'm still not convinced that we need the list structure in the first place. Why force us to use a list to mark up meta data? At this time I can see solid arguments for both sides, but what if in two years time we come back from the "meta data is list" idea? Then we're stuck with the current dl element.
div! The tag made for grouping. Or if you still want to use lists, two separate ul-li structures.
Apparently there's talk of "styling implied sections", but I'm not yet sure what that means exactly :) Sounds a lot like what you're talking about though.
Anders
Niels: I hear what you're saying. But CSS can't predict every possible change in layout we wish to accomplish. Sure it should be flexible. But it can only be flexible to a certain extent i believe. What if you suddenly decided that the fifth dt would need to be be absolutely positioned.
Here's an addition to my previous CSS that accomplishes what you're looking for. It might not be pretty, but it does the job without any extra markup, and is totally valid CSS, so I guess it's as good as anything: dt.editor:before {content:""; display: block; height: 0; visibility: hidden;}
Niels Matthijs
True, but that would be a specific exception in an otherwise rigid visual structure.
The point I'm trying to make is that the name-value pair (what's in a name :) is a very obvious unit that belongs together. I'm only talking positioning now, but what if you want a border around the pair? Again, it's possible in css, by defining borders on both dt and dd and removing the left/right, but all of this eats away at the flexibility of your css. What about a background-color? Maybe even a color fade. Or a background image that runs behind both elements. Can you image the css mess you'll be creating?
Everything points at the fact that people, for whatever reason, would want to target the name-value pair as a single unity. People see it as a unit, but html5 forbids you of turning it into a single unit. I just don't understand such limitations.
Anders
I absolutely agree with you! Perhaps the WHATWG would listen if the designers would raise their voices a bit more.
J.-Sébastien Girard
What I find most annoying is the fact that not only has DL been rendered absolutely useless for one its most obvious potential use (ontologies) by making it impossible to nest them, but the fact that DD is restricted to phrasing content negates the <a href="http://wiki.whatwg.org/wiki/FAQ#HTML5shouldgroup.3Cdt.3Esand.3Cdd.3Estogetherin.3Cdi.3Es.21">original retort</a> from WHATWG about the lack of list headers. You gotta applaud that kind of brilliant forward thinking.
Ultimately, I feel the problem (which you've outlined above) is that the elements are the only ones that encode an explicit semantic relation without a wrapper to connect them, which, in a language that relies on such wrappers everywhere else, is a simply terrible (and ultimately unworkable) idea.