On The <dl> (2021)

> <dl aria-label="Ability Scores">

This is incorrect:

1. <dl> has no corresponding (viz. implicit) role, but can be given the role group, list, none or presentation <https://w3c.github.io/html-aria/#el-dl>.

2. You’re only allowed to define aria-label on elements that have a compatible role, implicit or explicit <https://w3c.github.io/html-aria/#docconformance-naming>.

3. aria-label is allowed on all but a handful of roles <https://www.w3.org/TR/wai-aria-1.2/#aria-label>, which in this case knocks out presentation and none, leaving group and list.

4. group doesn’t feel right, list feels acceptable.

In summary: either ditch the aria-label, or add role="list" (meaning also role="listitem" on children).

—⁂—

One thing the article misses is that you can have multiple <dt> in a row too, not just <dd>. The spec has a good example: https://html.spec.whatwg.org/multipage/grouping-content.html...

They’re not name–value pairs, they’re name–value groups.

List history (listory?) lesson, kids: As the link below to a 1985 IBM mainframe DCF/GML manual shows, DL-DT-DD have been a thing since before the web. In addition to Definition lists (DL), the 40+ year-old documentation describes Glossary lists (GL), Ordered lists (OL), Unordered lists (UL), and Simple lists (SL).

ibm :: 370 :: DCF :: SH35-0050-2 Document Composition Facility Generalized Markup Language Implementation Guide Rel 3 Mar85

https://archive.org/details/bitsavers_ibm370DCFSpositionFaci...

This is going to be unpopular here, but life became easier when I quit trying to write semantic HTML. It’s just poorly designed, I’m sorry. Every time I’ve reached for a <dl> I’ve eventually regretted it because I wanted multiple levels of wrappers, or a divider between sections, or an icon, or a heading spanning multiple key-value pairs, etc. They make this stuff with some flexibility but nowhere near enough to actually cover the generalized concept it purports to. I still use the corresponding elements when there are observable benefits, of course, like <button>, <h1>, etc, but when all it’s going to do is not quite fit the data model and force me to override everything, it’s just not a practical choice.

It shouldn’t be so controversial to say that if 99% of usage routes around your API, it’s probably the API’s fault.

The world's first website makes heavy use of <dl>s.

https://info.cern.ch/hypertext/WWW/TheProject.html

https://info.cern.ch/ (A landing page of sorts to give context and orientation about the actual first website.)

> Prior to HTML5, this was called a definition list. This is because the <dl> was originally only intended to represent glossaries of terms and their definitions.

TIL I’ve been naming it wrong for a decade.

Here's a useful note on how well screen readers support DL: https://adrianroselli.com/2025/01/updated-brief-note-on-desc...

I've been following roadmap.sh, and while it's not a comprehensive learning resource, it does help close obvious knowledge gaps. As it happens I was just reading about this.

https://roadmap.sh/html (see "Definition lists")

The final example of the DnD statt sheet makes me think whether it's legal to nest <dl>s?

I.e. can we do

    <dl>
      <dt>Actions</dt>
      <dd><dl>...</dl></dd>
    </dl>

I love DL. I think tables, at least in the past, were misused as DLs even more in the past and the inconvenience of the table markup is even worse than a bunch of divs.

I'm curious if the spec actually says you can only wrap it with a div because I like to do semantic html and name my elements specific to my domain.

I've used this a good amount of times, when I coded in front end projects. The first time gave me that satisfying feeling of using the right tool for the job, like completing a puzzle of HTML semantics. I remember JAWS not announcing it correctly in 2018, not sure if it's better now.

> Admittedly, however, support for the <dl> element is not yet universal.

Wait what? <DL> has been in HTML since.. the first draft in 1993!

I like DL's but they can be challenging to style. This article is using a lot of fixed pixel widths which would break on really small screens or larger data.

I was a bit surprised to see nested <div>s given as some sort of precursor pattern, when <dl> was part of HTML before 2.0 back in the days of table layout.

The <dl> tag seems to cover a subset of a broad semantic space, but doesn’t easily extend beyond adding another <dd>.

I dunno, I guess I’m a caveman. If it looks right and works (including accessibility) then I figure I’m pursuing something that doesn’t matter a lot.

Hoped to see CSS for the alternative, where <div> is not nested inside the <dl>. Too used to thinking of div as "layout containers."

The GOV.UK Design System summary list component is a description list https://design-system.service.gov.uk/components/summary-list...

And... it also uses the wrapper div for styling

I loved the character sheet example! Fun!

We've always used this in our ebooks for abbreviation and glossary lists. The problem I've always had is that you need to use a bit of css to make two lined-up columns. I've done it with floats. Now, some ebook readers will support grid and flex-box, which give better results, but the Kindle still does not. Kindle is sort of the IE6 of the ebook world.

What about multiple '&lt;dt&gt;' for one or more '&lt;dd&gt;'?

This seems a clear enough win for things that would fit into a simple python dictionary.

Why is it preferred over <table> for laying out columns via a the character attributes at the bottom of TFA?

it's on archive html5 .flac 16-bit 44.1kHz no <dl> flag.

blog looks beautiful. I really wish I had this kind of talent for frontend.

It always bugs me that the naming of the element does not seem to really fit examples like „Author: Tolkien“. It‘s not that _Tolkien“_ „defines“ the „term“ _Author_ right? The elements are still used for key-value-lists and no one seems to notice or comment on this issue.

Am I the only one?

Good title

[dead]