On The <dl> (2021) | Hacker News Reader

On The <dl> (2021)

benmyers.dev

442 pointsravenical125 comments

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

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.

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.

I pulled up some of those spec's examples in Chrome and viewed the accessibility tree, and weirdly it assigns <dt> an implicit role of `term`, even though the spec says that <dt> should be `listitem` and <dfn> should be `term`. I didn't check FF or Safari but I would not be surprised if they did something different.

Given the spotty screen reader support for dt/dd to begin with, I'd steer clear of using multiple `<dt>` s if a11y is top priority, and just modify your content to have one dt per dd. Your single dt text could be "X or Y", repeat the definition twice, etc.

If you're familiar with Jakob's Law, it applies to a11y too, so stick with what users might have seen on other sites.

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

Concordantly, vis a vis, ergo..

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.

i.e. == aka == in other words

e.g. == f.e., for example

But both i.e. and e.g. might be more easily understood by non-native speakers of English (IMHO ;-)

"e.g." == exempli gratia == to give an example

"i.e." == id es == that is

The old HTML5 Doctor article is still my favourite https://html5doctor.com/element-index/

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.

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}

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

Seems the original ::contents proposal is where it's at now, though there hasn't been action on it for some time. Not sure if they hit a snag or it's just on the back burner

https://github.com/w3c/csswg-drafts/issues/2406

This proposal has the benefit of not violating the tree structure should multiple :wrap rules apply to overlapping elements.

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.

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.

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

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

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.

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

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

Cool, waiting for browsers to pick it up nice and green

I feel similarly about HTTP. The protocol maps really well to resource stores (stuff like S3). GET, PUT, DELETE all make sense. HTTP status codes are built exactly for this use case as well. But as web developers we're mostly not developing resource stores. Those are highly generic and can be built once and used by millions of apps. Most of the time someone is writing code that interacts with HTTP they are performing RPC. You can go for GraphQL, gRPC, or many other RPC systems that just shirk the whole thing. They make everything use a POST to a single endpoint and add another layer of abstraction so you don't need to return a 4XX/5XX error for some highly application-specific situation.

It's clear the RFC writers got a little out of hand. "402 Payment Required", "407 Proxy Authentication Required", "508 Loop Detected" look to me like attempts to work in functionality specific to certain types of apps or deployments. Why do these RFC authors get their specific needs implemented into the bedrock of the web and then expect me to find where my needs happen to overlap and then tuck every aspect specific to my app into "400 Bad Request" or "500 Internal Server Error"? Every time I see a web app actually utilize more than the bare minimum of HTTP status codes I roll my eyes. Put that shit into the application layer. The protocol wasn't made for you. It was made for LAMP-stack apps serving mostly static assets.

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

Isn't it description list?

FWIW, the Wikipedia page on "HTML elements" says:

>A description list (a.k.a. association list or definition list)[...]

The "Definition list" Wikipedia article is a redirect to that paragraph.

https://en.wikipedia.org/wiki/HTML_element#dl

I believe IBM Generalized Markup Language evolved into SGML (Standard Generalized Markup Language) which was used heavily at CERN when Tim Berners-Lee was working on HTML, which is heavily derived from it. I find this interesting about HTML: some form of the markup language had been floating around for decades until Berners-Lee added hyperlinks to it.

GML dates to 1969, SGML from the 1970s. Internally we used something called BookMaster which kind of? looks like a precursor to HTML (you had :p. instead of <p>, :li. instead of <li>). There was an effort circa 1990-1991 (as TBL was developing HTML and HTTP) called HyTime which was an SGML application focused on hypermedia. HTML killed that fairly quickly.

See https://en.wikipedia.org/wiki/Charles_Goldfarb who shepherded GML/SGML and https://en.wikipedia.org/wiki/Standard_Generalized_Markup_La...

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

Good website. It's responsive.

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

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

> I think it may be north of a decade

Nearly two!

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

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

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

TIL The name was changed from a definition list.

Same here. I like definition list better ;-)

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

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

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

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

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.

So then what's the point of making this distinction? I would like to see surveys of how many people actually author content in forms that differentiate between b and strong.

What, you don't know what's the difference between "emphasis" and "bringing attention to"? Shame on you, shame on you: you're unworthy to write HTML.

The difference, of course, is that one is a Latin word, and the other is an English phrase with the same meaning. But they're different words, so different tags. It's all completely rational and logical, and if you don't see the logic and/or reason, well: you're unworthy to write HTML. See Figure 1.

P.S. I love this ancient "see figure 1" meme. It's originated in the early 80s, and still as relevant as ever, and probably will be forever.

    Please stop submitting SPR's.  This is our system.  We designed
    it, we built it, and we use it more than you do.  If there are some
    features you think might be missing, if the system isn't as effective
    as you think it could be, TOUGH!  Give it back, we don't need you.
    See figure 1.

           ---------------------------
           !            -            !
           !           { }           !
           !           | |           !
           !           | |           !
           !        .-.! !.-.        !
           !      .-!  ! !  !.-.     !
           !      ! !       !  ;     !
           !      \           ;      !
           !       \         ;       !
           !        !       :        !
           !        !       |        !
           !        |       |        !
           !                         !
           ---------------------------
                     Figure 1.

I also enjoy this classic meme. The full version is here: https://www.dourish.com/goodies/see-figure-1.html

Some phrases have stuck with me, like “mandatory defaults“, “they told their users to see figure 1 a long time ago” and the flippant “sometimes we blow it though”.

Because the elements already exist. When the elements were invented and defined, CSS didn't exist and authors had to use elements to make presentational changes. When HTML5 was defined, CSS was well established and it was an opportunity to update element descriptions to get rid of specific presentational qualities.

There are lots of elements, if you don't find some of them useful, don't use them. Other people may find uses for the distinctions; even if they use distinctive styling for them all, they may need to document why they're used, not just for all the authors but for the audience as well; clearly we can't expect developers to know what all the elements are for so that's doubly true for the audience.

Personally I think we should declare that b and strong mean the same thing, and that i and em mean the same thing. As the other commenter points out, there's no real semantic difference between "bring attention to" and "emphasize".

> So then what's the point of making this distinction?

It keeps the semantic web people busy not doing too much damage. Otherwise we might get an XHTML3 or CSS4 based on RDF triples or some such horror.

The entire purpose of an element like <b> is what it looks like. If we're being inclusive, then the entire purpose of an element like <b> is what it looks like, how it sounds, how it feels in Braille, and so on. Nothing more. It does not map to some abstract concept.

It should be defined as: When rendered on a visual display device supporting bold font, it makes the text bold. The specific behavior is not guaranteed and may vary based on the user-agent. For example, screen readers will pronounce the text with emphasis.

The entire purpose of <b> was what it looked like. They changed its definition to not be about what it looked like but why an author might make it look that way, i.e. to bring attention to it. The representation flows from the motivation, there's no need to embed a look in the definition.

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

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>

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

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

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

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

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.

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.

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

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

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

Isn't markdown table just a bunch of | ?

That's the problem.

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

Every markdown implementation is supposed to allow inline HTML.

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

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

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

yes, that's what I meant, indeed.

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>

> if you omit unnecessary closing tags

As someone who had written lots of XHTML in the past, not having closing tags makes my eyes twitch like Scrat in Ice Age. I even occasionally write `<br>` like `<br/>` out of habit.

> <br/>

Only occasionally? I will die on this hill.

Yes yes, someone is about to tell me that Opera running on a PS Vita with the language set to Basque will display those incorrectly. That ISO 714-4BΔ-鸡冠 defines them as undefined, and prohibits them within eight clock ticks of C sequence points. That Apple charges an extra 1% app store commission for them (except where prohibited by court injunction).

Call it a concession to my sanity. A song of saner days.

Someone here. OP most certainly knows that precisely, but for the rest: It was Netscape® Communicator, which interpreted everything after `<` up to either white-space or `>` as a tag name. Technically that wasn't even that much incorrect, but amusingly, since the HTML "specs" then still stemmed from SGML, the really correct outcome of `<br/>` (and even `<br />` with a space before the "closing" solidus) back then should have been to both emit the (empty, by definition) BR element (⁕) and a dangling `>` text node after that. No consumer-facing HTML client really implemented that. Netscape simply took it as unknown "BR/" tag and didn't render anything in its place.

In the late '90s Netscape was a niche browser with negligible 80% market share. The real and eternal XHTML enlightenment had begun a few years later, in the early 2000s and reached near eternal duration of seven years.

Also, https://jakearchibald.com/2023/against-self-closing-tags-in-... provides a broad perspective on the topic (but I guess it is very unlikely anyone reading this hasn't seen that article already).

Practically, using `<br />` in HTML with space was safe, like, forever, except for original W3C validator and Amaya. Using `<br/>` is safe since around 2002-2008 when Netscape was dying. In 2026, you can throw basically anything at current browsers and it will repair it to something meaningful, as per the living HTML spec. You can go `</br/r/r>`, if you are really into solidi, and it will work the same as `<br>`.

Disclosure: I also clearly see how having stupid simple "XML-like" syntactic rules would be beneficial in the grand scheme of things compared to what HTML became: memorising the "VOID" HTML elements by heart, and having to implement this in every HTML processing product clearly creates significant mental and processing overhead. But FMPoV, it's just one inconvenience we should begrudgingly accept at this point, rather than fight it.

(⁕) In reality, the way browsers treat `<br>` in the document flow is more like a text node than element node, but it's just an implementation detail orthogonal to this topic.

Fantastic comment! Really lovely contribution. The sort of thing I come to HN for.

> You can go `</br/r/r>`, if you are really into solidi

Love it.

Haha, blushing in awkward uncertainty that I've failed to detect irony …? (Is this HN, right?) But even if, thanks anyway! I'm glad I could vent the lore I've spent gathering in unhealthy amount of unproductive research; I cannot imagine better place to finally bury that than deep in super-tangential HN discussion…

No no, dead earnest. I'm a big believer in honest compliments, where merited.

Please start writing a blog, if you don't already. If I could compose a blog roll of people writing fun CS histories, I would replace my HN bookmark with it.

You cannot close HTML tags that way anyways, <br> and <br/> are the same, as are <div> and <div/>. The spec defines whether an element self-closes, the slash is just ignored.

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

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.

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

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

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

Custom-named elements are divs.

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.

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.

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

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

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.

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.

Great post. Very minor nitpick: ‘The small element must not be used for subheadings; for that purpose, use the hgroup element.’

‘The small element represents side comments such as small print. Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements.’

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

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.

When I checked in 2024 or 2025, Windows Narrator announced it differently in Chrome, Firefox, Edge (Chromium mode) and Edge (IE mode), and none of them worked how I would expect them to. Adrian Roselli's verdict (https://adrianroselli.com/2025/01/updated-brief-note-on-desc...):

> Description list support continues to be generally good (with VoiceOver still the outlier), even if you may not like how it is supported.

You shouldn't try to fix this kind of thing by mangling the HTML, since (1) users tend to be used to their screen reader's quirks, and (2) in situations like these, making it juuuust right in one screen reader is likely to make it incomprehensible in another. But it is important to be aware of these quirks, so you don't accidentally design an interface that relies on less-quirky behaviour.

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

Granted, I do not know what I am doing with CSS, but the Character Sheet example seems standard flexible elements?

Some of the extracted CSS chunks

  #statblock{
    box-shadow:0 20px 25px -5px rgba(0,0,0,.1),0 10px 10px -5px rgba(0,0,0,.04);
    font-family:Lato,'Trebuchet MS',sans-serif;
    font-size:85%;
    min-width:50ch;
    max-width:70ch;
    margin-inline:auto;
    background-color:#fffaf0;
    padding-inline:2rem;
    padding-block:1rem
  }
  dl.statblock-bio{
    color:maroon;
    line-height:1.5;
    border-top:5px solid maroon;
    border-bottom:5px solid maroon;
    margin-block:0.75em;
    padding-block:0.75em
  }
  dl.ability-scores{
    min-width:40ch;
    display:flex;
    justify-content:space-around;
    color:maroon
  }
  dl.ability-scores>div{
    text-align:center;
    line-height:1.5
  }
  dl.ability-scores dt{
    font-weight:700
  }

I've found CSS Grid is extremely useful for styling DLs.

Well, it took about a decade for web standards to become a real thing and a lot longer for Web Platform Tests to come to be. Still, while there are lots of tests for DOM construction and visual rendering, testing construction of the accessibility tree is lacking (also keyboard interaction testing).

And that's just for browsers, there's no shared spec for the operating system accessibility APIs the browsers' accessibility tree has to be translated into or how screen readers (and other assistive technologies) will use the OS's APIs.

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?

Aside from the accessibility benefit mentioned in the article, I would think that using semantic HTML like this would also make AI tools more effective at understanding code

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.

It’s probably aimed at React developers, many of which are probably not even aware that elements other than <div> exist.

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

CSS Grid is a very good friend when trying to style DL without extra DIV wrappers. An example:

    dl {
        display: grid;
        grid-template-columns: 1fr 3fr;
        grid-template-rows: auto;
    }

    dt {
        grid-column-start: 1;
    }

    dd {
        grid-column-start: 2;
    }

That very simply puts terms side-by-side data in a nice obvious way. (Even with multiple DDs per DT.) A bit like the Wikipedia screenshot in the article but that's more balanced `grid-template-columns: 1fr 1fr;`. (But that's the flexibility of CSS Grid, right? Real easy to tweak this further for your needs/interests/design.)

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

The wrapper div is making me a bit sad. These days, using grid layout, you don’t actually need it in most cases

Absolutely!

I put dl lists in a grid with no divs needed. As MDN says, div is the last resort, invariably there is something better, and nowadays that is grid styling.

New to me is multiple dd's.

For legacy layouts littered with divs and classes, display: contents helps get rid of the div wrappers, promoting whatever is wrapped.

Even with disclosure elements there are ways to avoid div wrappers using the pseudo element for everything enclosed by the details element apart from the summary element.

The problem with 'in most cases' when it comes to a design system that's used in hundreds of different ways across departments and services, is that some week break.

I don't really like the div either (I use the design system all day, and maintain a set of components), but it makes documentation much easier.

I loved the puzzle of thinking about the best semantic representation of content in HTML. Good times

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.

Shameless plug: you might be interested in https://calvinlc.com/p/2026/02/11/everything-is-a-div.html

I need to learn more about web accessibility, but if you completely ignore it (and other sane practices) HTML looks really simple.

I think the design of HTML is just too much. There’s so many tags that don’t do much. It’s like w3c decided that any common thing people use in websites needs a tag. The end result is more and more tags…

Can anyone convince me otherwise? It screams design red-flags to me.

PS: I love the web and think it’s the best platform and future platform we have at the moment. It’s just quirky and loves not breaking old websites!

Oh that’s great. It’s an opinionated view that focused strictly on the behavior of the tags wrt layout and appearance.

I’ve noticed that discussions of semantic meaning of tags often contain the word “feel.” Nothing wrong with that, taste matters, but it does point to the non-functional goals that are being pursued when people disagree.

<ol> vs <ul> - they are both ordered, because markup is ordered. One gets decorated differently than the other by default. Is the difference semantic or typographical?

A <ul> is a list of things whose order makes no difference to its meaning. Rearranging a <ul> would change the presentation, not the information. Rearranging an <ol> would change both.

  <ul> Players
    <li> Alice
    <li> Bob
    <li> Carol
  </ul>

  <ol> Leaderboard
    <li> Bob
    <li> Alice
    <li> Carol
  </ol>

Exactly. “Unordered” implies “reordering doesn’t change meaning.” And yet that’s already implicit in the bullets (vs numbers).

So is it a decoration hint? Or is it actually semantic? And what system is interpreting the semantics rather than the visual presentation?

HyperText Markup Language is semantic. You're marking up a document to show what information it contains, where it contains it, and how it relates to other documents or information. Reading markup causes browsers to display things, but that's incidental.

In theory.

In practice, no one cares about semantics and the choice of tags is based on how a target set of browsers happens to display them.

Your question about who interprets markup is exactly right. In theory, you have no idea. Maybe it's a browser, maybe it's assistive software, maybe it's a browser printing, maybe it's some custom knowledge base with different views of documents for different users. In theory, you're supporting all of that by only marking up semantics and allowing the consumer to interpret them, because there isn't one right answer.

In practice, your client is Chrome.

In theory, that's irrelevant because you're using CSS to style semantic markup so it works in Chrome and still makes sense to other clients.

In practice, you're writing a web application, using a framework, and nothing in the stack wants you to do that.

> nothing in the stack wants you to do that

Meaning treat semantic markup as a principle. Most modern tools are not that interested in 2010s ideas about separation of design and content.

Too late to edit now, but I should mention putting titles in a list like that isn't valid. It's just to shorten the example.

lol, you should actually read the HTML spec, there are good explanations of all the elements. The whole point of defining semantics is that elements have meaning independent of their default appearance (or any appearance).

> I need to learn more about web accessibility, but if you completely ignore it (and other sane practices) HTML looks really simple.

Everything looks really simple when you ignore vast amounts of the subject and nuance.

Your rules don't mention keyboard or focus behavior, the only mention of either is the association between <label> and its <input>. <output> does have functionality, it's an HTML-native ARIA live region (that can be associated with a <label>).

https://html.spec.whatwg.org/multipage/

What about multiple '<dt>' for one or more '<dd>'?

I loved the character sheet example! Fun!

All the native GUI toolkits are dead, but people can write entire essays now on a single HTML element. I guess that's progress?

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

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

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?

As the article points out, HTML5 softened the name from "definition list" to "description list" to move it a bit away from thinking of it as a "dictionary" definition and somewhat better reflect how it has always been used.

Good title

Reply on news.ycombinator.com