On The <dl> (2021) - Hacker News

Posted by ravenical 6 hours ago

On The <dl> (2021)(benmyers.dev)

288 points | 88 comments

chrismorgan 4 hours ago|

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

redmatter 3 hours ago||

Wow I have never noticed that, thanks for the heads up! Out of curiosity, would you put `role="listitem"` on `<div>` elements that wrap the `<dt>` && `<dd>` elements? It looks like `role="listitem"` is allowed on the `<dt>` element, but that doesn't feel like it would be accurate in the case where multiple `<dt>` elements are grouped together, and I'm not sure if that would mess with how the element is interpreted natively as as term.

chrismorgan 3 hours ago||

I know the fundamentals of this sort of thing, but I haven’t done much practical with it, so I don’t feel that I can comment on this point.

brewmarche 2 hours ago|||

Your comment put me on a side quest to research the differences between i.e., e.g., viz. and sc. and I have to admit that I’m still not 100% sure

chrismorgan 57 minutes ago|||

Don’t think I’ve ever heard of scilicet. <https://books.google.com/ngrams/graph?content=viz.,sc.&year_...> definitely suggests viz. to have been massively more popular than sc.

HappMacDonald 59 minutes ago|||

Concordantly, vis a vis, ergo..

huflungdung 3 hours ago||

[dead]

theodpHN 11 minutes ago||

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

kqp 3 hours ago||

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.

halapro 3 hours ago||

Sounds like it's CSS' fault then. I think that just like they introduced `display:contents` to remove wrappers, they should also introduce a way to group elements as if they had a common ancestor.

    :wrap(dt, dt+dd) {border: solid 1px}

eurleif 1 hour ago|||

Proposal from 2016 (closed): https://github.com/w3c/csswg-drafts/issues/588

WorldMaker 1 hour ago||||

With CSS Grid math you can fake it, at least. If your DL is `display: grid;` and if you have a few extra DIVs lying around at the bottom of the DL to be borders around combined cells you just have to math which rows/columns you want to draw a border around and make the div fit that combined shape.

cubefox 1 hour ago|||

Good idea. Together with ::after / ::before and content: (which can insert text into the website) it might then be possible to create a website without any HTML, only CSS.

miki123211 2 hours ago||

As a person who daily drives a screen reader, I so agree with this.

We'd all be better off if the W3 dispensed with all that ideological semantic purity BS and started doing more realpolitik. Think not about whether your API is semantically pure, but about what developers want to do, what hacks they'll use to achieve their goals despite your objections, and how to enable doing those things in a way that is maximally beneficial to everyone involved.

ARIA live regions are the perfect example. What developers actually want is `document.speakText`. What developers actually have is a weird API that announces text on the page as it changes. They have to bridge from one to the other, which is difficult and hacky, even when implemented well. But hey, at least that live region approach is semantically pure HTML...

SebastianKra 1 hour ago|||

I don't want that. I don't want to care about screen readers (unfortunately I have to). I want a system where I can pick well-defined rules and then css can style it, screen readers will understand it, automations can parse it, keyboard navigation is free.

Obviously thats not what we got, but I feel like the set of established UI patterns is manageable enough that it could be built.

A great example is the new <select> styling that developers styled in all kinds of creative ways. Now give me that for comboboxes, trees, data-grids etc...

extra88 59 minutes ago||

There are already well-defined rules, you just don't like some of the rules, e.g. you can't (today) style <select> options. Keyboard navigation is free as long as you follow the rules about which elements are focusable.

You shouldn't have to care about screen readers the same as you shouldn't have to care which browser someone uses but you always have to care about people; people who can't see or hear what you create, people who can operate a keyboard (or keyboard-equivalent) but not a mouse or touchscreen, people who can use a touchscreen but not a physical keyboard, etc.

extra88 1 hour ago|||

Good news! `.ariaNotify()` is basically a real implementation of your hypothetical document.speakText.

https://developer.mozilla.org/en-US/docs/Web/API/Element/ari...

jimbosis 4 hours ago||

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

captn3m0 5 hours ago||

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

sunshowers 1 hour ago||

Bleh. <b> is apparently now bring attention to. As if.

extra88 48 minutes ago|||

Eh, it's fine, elements should be defined for what they mean, not what they look like. The explanation and distinctions made between <b> and other elements (<i>, <em>, <strong>) make sense.

The suggested (not obligatory) user agent styling for <b> is `font-weight: bolder` an agent or authors could use lots of different things to bring attention to what the element contains and treat it differently from <strong>.

https://html.spec.whatwg.org/multipage/text-level-semantics....

https://html.spec.whatwg.org/multipage/rendering.html#phrasi...

sunshowers 38 minutes ago||

I write most of my content in markdown or asciidoc and I don't pay attention to whether it's b or strong :)

extra88 4 minutes ago||

In practice today, that's fine. Typically authors have a hard time differentiating what "emphasis," "importance," and "bring attention to" mean to them. Therefore, nothing conveys a distinction by default.

Ancapistani 3 hours ago|||

You’re not alone. This is the second time this week I’ve seen that, and thought it was a mistake the first time.

xp84 4 hours ago|||

I don’t want to check what year html5 was standardized because I think it may be north of a decade ;)

zbentley 3 hours ago||

> I think it may be north of a decade

Nearly two!

stouset 3 hours ago||

I was better off not knowing that this morning. Might be worth prefixing that tidbit of info with “trigger warning: the unrelenting passage of time”.

HappMacDonald 56 minutes ago||

There exist toddlers who were raised on Teletubbies that are now members of Congress

stouset 41 minutes ago||

I’m going to have to politely request that you stop this immediately.

jasonlotito 4 hours ago||

TIL The name was changed from a definition list.

Tepix 3 hours ago||

Same here. I like definition list better ;-)

gste 24 minutes ago||

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

simonw 5 hours ago||

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

cloud-oak 5 hours ago||

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>

perilunar 4 hours ago|

Yes. Any flow content is permitted inside a <dd>. See:

https://html.spec.whatwg.org/#the-dd-element

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

myfonj 4 hours ago|||

Plus, when curious about formal syntactic correctness, there is the validator.w3.org [1].

[1] https://validator.w3.org/nu/?showsource=yes&showoutline=yes&...

moron4hire 4 hours ago|||

I do it to render nested JSON objects, for example.

Demiurge 5 hours ago||

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.

enriquto 4 hours ago||

It's not that inconvenient if you omit unnecessary closing tags:

    <tr>
    <td> first
    <td> second
    <tr>
    <td> what
    <td> ever

I find it simpler and cleaner than any of the markdown table markups

myfonj 4 hours ago|||

Fair point, though /DT and /DD are also optional just like /TH, /TD and /TR are. So in effect, def…scription list could structurally save you one TR for each entry and two "BLE"s:

    <table><tr><th>Term 1<td>Definition 1
           <tr><th>Term 2<td>Definition 2
    </table>
    <dl><dt>Term 1<dd>Definition 1
        <dt>Term 2<dd>Definition 2
    </dl>

debesyla 4 hours ago|||

Isn't markdown table just a bunch of | ?

zufallsheld 4 hours ago||

That's the problem.

froh 4 hours ago||

most specifically the problem is that markdown tables don't allow breaking the table row in multiple lines

but then you can always use HTML tables in markdown and Pandoc transforms it just fine

hnlmorg 4 hours ago|||

<br> has worked fine whenever I’ve needed line breaking in markdown tables

quietbritishjim 2 hours ago|||

I think they mean breaking the line in the markup, not the output

xigoi 3 hours ago|||

They mean in the Markdown code, not in the output.

jazzypants 4 hours ago|||

Every markdown implementation is supposed to allow inline HTML.

bdcravens 4 hours ago|||

You're right, but forcing tables to cosplay as DLs was far from the worst way that tables were abused.

sodapopcan 4 hours ago||

At least <td>s could easily centre things vertically ;)

egeozcan 4 hours ago||

I always thought the DL as a single row of a table.

phyzix5761 5 hours ago|

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.

notnullorvoid 3 hours ago||

As others have noted only the div is allowed. This isn't a unique situation either, the HTML spec despite being lenient in syntax is quite restrictive in behavior. It's unfortunate that XHTML (and XML parsing) didn't become the default as it's the opposite, more restrictive syntax, but lenient behavior.

For example in XHTML you can use custom elements as table rows or cells (provided you give them the correct role and CSS display property). This is because XHTML does not modify the tree during parsing, unlike HTML which will hoist out custom element children of the table to the table's parent.

philo23 5 hours ago|||

Yep, I was a little surprised about that too, seem like it is valid though https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

wonger_ 5 hours ago|||

Seems like div is the only recommended wrapper element:

https://html.spec.whatwg.org/multipage/grouping-content.html...

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

EDIT everyone replied at once lol. I'm surprised too about div.

Also, screen reader support: https://a11ysupport.io/tech/html/dl_element

Tomte 5 hours ago|||

Yes: https://html.spec.whatwg.org/multipage/grouping-content.html...

moron4hire 4 hours ago||

Custom-named elements are divs.

phyzix5761 3 hours ago|||

They're not as you can see here[1] and here[2]. They both inherit from the HTMLElement interface but div is considered an HTMLDivElement which makes it distinct from a custom element.

<my-element> != <div>

[1] https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...

[2] https://developer.mozilla.org/en-US/docs/Web/API/HTMLDivElem...

moron4hire 14 minutes ago|||

HTMLDivElement has no properties or methods not inherited from HTMLElement. If you inspect the user-agent styling of div versus any non-standard named element, you'll see that they have the same styling path, specifically unlike with span. In other words, non-standard elements and divs are all block elements with the default HTMLElement attributes and methods.

The use of HTMLElement and HTMLUnknownElement for the non-standard elements is to support future additions to the standard elements and enable subclassing down-tree instead of across-tree, which is noted in the spec.

jazzypants 4 hours ago||||

Exactly! It cracks me up when people name-check "semantic elements" when it doesn't actually mean anything in that context. Accessibility software doesn't understand the semantics of your custom elements, so there is no benefit in that situation whatsoever. Maybe it's easier for you to read and edit in the future, but that's it.

Somehow, people got convinced that <div> elements are evil and should never be used no matter what. Yes, you should use a more semantic element when it makes sense, but try to remember what that phrase actually means.

phyzix5761 3 hours ago||

I use it for readability and to express intention and meaning to the reader of my program. In the age of AI, perhaps, we've lost the need for that. But it was much appreciated in times before by those who came upon my code.

jazzypants 3 hours ago||

That's great! There's nothing wrong with that.

However, "semantic elements" became popular shortly after the push for the "semantic web" which was entirely based around making the web easier to process for machines. Many of the original sources talk about how it's easier to digest for humans too, but that's just a happy byproduct.

https://www.w3.org/DesignIssues/Semantic.html

https://www.lassila.org/publications/2001/SciAm.pdf

https://informationr.net/ir/7-4/paper134.html

https://jonchristopher.us/blog/a-semantic-breakdown-of-resta...

https://shapeshed.com/the-importance-of-semantic-markup/

https://www.w3.org/TR/html-design-principles/

https://microformats.org/wiki/posh

More comments...