logoalt Hacker News

On The <dl> (2021)

276 pointsby ravenicaltoday at 1:03 PM83 commentsview on HN

Comments

chrismorgantoday at 3:00 PM

> <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.

show 3 replies
kqptoday at 4:30 PM

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.

show 2 replies
jimbosistoday at 2:59 PM

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.)

captn3m0today at 1:57 PM

> 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.

show 3 replies
simonwtoday at 2:29 PM

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

cloud-oaktoday at 2:09 PM

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>
show 1 reply
Demiurgetoday at 2:29 PM

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.

show 3 replies
phyzix5761today at 1:51 PM

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.

show 5 replies
rickstanleytoday at 1:50 PM

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.

show 1 reply
tlntoday at 2:50 PM

> 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.

Telemakhostoday at 1:49 PM

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.

shermantanktoptoday at 3:06 PM

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.

show 1 reply
turtleyachttoday at 1:15 PM

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

michalctoday at 2:18 PM

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

show 1 reply
gabriela_ctoday at 5:19 PM

I loved the character sheet example! Fun!

Finnucanetoday at 3:46 PM

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.

gbeardishtoday at 2:19 PM

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

smitty1etoday at 2:56 PM

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?

mockbuildtoday at 2:38 PM

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

jdw64today at 2:11 PM

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

lechimptoday at 5:08 PM

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?

show 2 replies
MattRixtoday at 2:04 PM

Good title

alanbottstoday at 6:17 PM

[dead]