On The <dl> (2021)(benmyers.dev) |
On The <dl> (2021)(benmyers.dev) |
Am I the only one?
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.
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.
e.g. == f.e., for example
It shouldn’t be so controversial to say that if 99% of usage routes around your API, it’s probably the API’s fault.
ibm :: 370 :: DCF :: SH35-0050-2 Document Composition Facility Generalized Markup Language Implementation Guide Rel 3 Mar85
https://archive.org/details/bitsavers_ibm370DCFSpositionFaci...
See https://en.wikipedia.org/wiki/Charles_Goldfarb who shepherded GML/SGML and https://en.wikipedia.org/wiki/Standard_Generalized_Markup_La...
>A description list (a.k.a. association list or definition list)[...]
The "Definition list" Wikipedia article is a redirect to that paragraph.
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.)
TIL I’ve been naming it wrong for a decade.
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.e. can we do
<dl>
<dt>Actions</dt>
<dd><dl>...</dl></dd>
</dl>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&...
<tr>
<td> first
<td> second
<tr>
<td> what
<td> ever
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.
<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>‘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....)
> 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.
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
#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
}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.
Why is it preferred over <table> for laying out columns via a the character attributes at the bottom of TFA?
dl {
display: grid;
grid-template-columns: 1fr 3fr;
grid-template-rows: auto;
}
dt {
grid-column-start: 1;
}
dd {
grid-column-start: 2;
}
https://roadmap.sh/html (see "Definition lists")
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.
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!
> 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>).
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?
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...
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...
https://developer.mozilla.org/en-US/docs/Web/API/Element/ari...
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.
:wrap(dt, dt+dd) {border: solid 1px}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.
"i.e." == id es == that is
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.
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.
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.
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/
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.
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.
> You can go `</br/r/r>`, if you are really into solidi
Love it.
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.
but then you can always use HTML tables in markdown and Pandoc transforms it just fine
<ul> Players
<li> Alice
<li> Bob
<li> Carol
</ul>
<ol> Leaderboard
<li> Bob
<li> Alice
<li> Carol
</ol>So is it a decoration hint? Or is it actually semantic? And what system is interpreting the semantics rather than the visual presentation?
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.
Meaning treat semantic markup as a principle. Most modern tools are not that interested in 2010s ideas about separation of design and content.
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.
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.
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.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”.
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.