On The (2021) • Hacker News Board

Re: On The <dl> (2021)

#81

Post by WorldMaker » Sat, May 23, 2026, 6:30 PM UTC

turtleyacht wrote: post #2

Hoped to see CSS for the alternative, where is not nested inside the . 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.)

Re: On The <dl> (2021)

#82

Post by extra88 » Sat, May 23, 2026, 6:31 PM UTC

miki123211 wrote: post #71

kqp wrote: post #62

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

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…

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

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

Re: On The <dl> (2021)

#83

Post by WorldMaker » Sat, May 23, 2026, 6:33 PM UTC

lechimp wrote: post #69

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.

Re: On The <dl> (2021)

#84

Post by [deleted] » Sat, May 23, 2026, 6:35 PM UTC

sunshowers wrote: post #76

captn3m0 wrote: post #10

> Prior to HTML5, this was called a definition list. This is because the was originally only intended to represent glossaries of terms and their definitions. TIL I’ve been naming it wrong for a decade.

Bleh. is apparently now bring attention to . As if.

[deleted]

Re: On The <dl> (2021)

#85

Post by [deleted] » Sat, May 23, 2026, 6:37 PM UTC

xigoi wrote: post #65

Telemakhos wrote: post #4

I was a bit surprised to see nested s given as some sort of precursor pattern, when 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 exist.

[deleted]

Re: On The <dl> (2021)

#86

Post by HappMacDonald » Sat, May 23, 2026, 6:39 PM UTC

brewmarche wrote: post #72

chrismorgan wrote: post #31

> This is incorrect: 1. 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-…

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

Re: On The <dl> (2021)

#87

Post by extra88 » Sat, May 23, 2026, 6:40 PM UTC

SebastianKra wrote: post #80

miki123211 wrote: post #71

Earlier quoted context omitted.

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…

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

There are already well-defined rules, you just don't like some of the rules, e.g. you can't (today) style 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.

Re: On The <dl> (2021)

#88

Post by chrismorgan » Sat, May 23, 2026, 6:41 PM UTC

brewmarche wrote: post #72

chrismorgan wrote: post #31

> This is incorrect: 1. 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-…

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

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.

Re: On The <dl> (2021)

#89

Post by HappMacDonald » Sat, May 23, 2026, 6:43 PM UTC

stouset wrote: post #53

zbentley wrote: post #45

Earlier quoted context omitted.

> 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

Re: On The <dl> (2021)

#90

Post by extra88 » Sat, May 23, 2026, 6:51 PM UTC

sunshowers wrote: post #76

captn3m0 wrote: post #10

> Prior to HTML5, this was called a definition list. This is because the was originally only intended to represent glossaries of terms and their definitions. TIL I’ve been naming it wrong for a decade.

Bleh. 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 and other elements (, , ) make sense.
The suggested (not obligatory) user agent styling for 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 .
https://html.spec.whatwg.org/multipage/text-level-semantics....
https://html.spec.whatwg.org/multipage/rendering.html#phrasi...

Permalink View on HN Reply on HN Top