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>.
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.
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.
> 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.
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.
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:
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 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.
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.
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.
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.
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.
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.
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!
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.
> 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.
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.
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.
It shouldn’t be so controversial to say that if 99% of usage routes around your API, it’s probably the API’s fault.
TIL I’ve been naming it wrong for a decade.
Nearly two!
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.)
I.e. can we do
https://html.spec.whatwg.org/#the-dd-element
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
[1] https://validator.w3.org/nu/?showsource=yes&showoutline=yes&...
but then you can always use HTML tables in markdown and Pandoc transforms it just fine
And... it also uses the wrapper div for styling
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 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.
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.
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
<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...
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.
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
> 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.
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.
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!
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.
Some of the extracted CSS chunks
Why is it preferred over <table> for laying out columns via a the character attributes at the bottom of TFA?