- , and
- in HTML5
- , and
- in HTML5
Join the DZone community and get the full member experience.Join For Free
Jumpstart your Angular applications with Indigo.Design, a unified platform for visual design, UX prototyping, code generation, and app development.
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:
"The dl element represents an association list consisting of zero or more name-value groups (a description list)."
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.
/* 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>
Published at DZone with permission of Niels Matthijs , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.