{"slug": "on-the-dl-2021", "title": "On The
(2021)", "summary": "The article explains that the HTML `
` (description list) element, along with its child elements `
` (description term) and `
` (description detail), is an underused but semantic way to mark up lists of name-value pairs, such as book details or lodging amenities. It argues that using these elements instead of nested `
`s provides accessibility benefits for screenreader users, who can then navigate the list more efficiently. The author notes that while support for `
` is not yet universal, its semantic value makes it a strong candidate for representing such data patterns.", "body_md": "Introduction\nThe
\n, or description list, element is underrated.\nIt’s used to represent a list of name–value pairs. This is a common UI pattern that, at the same time, is incredibly versatile. For instance, you’ve probably seen these layouts out in the wild…\nEach of these examples shows a list (or lists!) of name–value pairs. You might have also seen lists of name–value pairs to describe lodging amenities, or to list out individual charges in your monthly rent, or in glossaries of technical terms. Each of these is a candidate to be represented with the
\nelement.\nSo what does that look like?\nThe Anatomy of a Description List\nI’ve been saying “
\n,” when really, I’m talking about three separate elements:
\n,
\n, and
\n.\nWe start with our
\n. This is the description list, akin to using a note 1
    \nfor an unordered list or an
      \nfor an ordered list.\nFancy.\nNext up, we want to add a name–value pair. We’ll use a
      \n, short for description term, for the name, and we’ll use a
      \n, short for description detail, for the value. note 2\nTo add another name–value pair to our list, we add another
      \nand
      \n:\nBut wait — what if I have a term that has multiple values? For instance, what if this book has multiple authors?\nThat’s fine! One
      \ncan have multiple
      \ns:\nThere’s one last piece of the description list anatomy to look at for most basic use cases: what if I want to wrap a
      \nand its
      \n(s) for styling reasons?\nIn this case, the specs allow you to wrap a
      \nand its
      \n(s) in a
      \n:\nA wrapper
      \nlike this is the only element that can wrap those
      \n/
      \ngroups.\nAnd that’s it! That’s the anatomy of the description list, HTML's semantic way to mark up a list of name–value groups!\nWhy Do We Need Semantics For This Anyways?\nBefore we learned about the
      \n,
      \n, and
      \nelements, my team used to use nested
      \ns for this pattern all the time. It looked a lot like:\nThis has all the information about the book, right? Why do we need semantics for a list of name–value groups in the first place if something like a series of nested
      \ns could get the job done?\nWhen determining whether a semantic element might be appropriate for a given pattern, I find it helpful to ask, “What benefits — even theoretical — could we get if computers could recognize this pattern?” In this case, what lift could we get if browsers could somehow recognize a list of name–value groups?\nAnswers to that question will be varied. I tend to spend a lot of time advocating for web accessibility, so my first thought tends to be how screenreaders could interpret the pattern. Off the top of my head, I can think of a couple of benefits screenreader users could get from their screenreaders recognizing this pattern:\n- The screenreader could tell the user how many name–value groups are in the list.\n- The screenreader could tell the user how far into the list they are.\n- The screenreader could treat the list as one block that the user could skip over if they’re uninterested in it.\nAll of these could make the list more usable than a series of nested
      \ns, which would treat each name and value in the list as nothing more than a standalone text node.\nIf you can come up with a couple of even theoretical lifts from the user’s device recognizing a pattern, then there’s a good chance that the pattern is a strong candidate for having some associated semantics.\nFor what it’s worth, these screenreader experiences aren’t hypothetical — they’re benefits that screenreader users really get from using
      \nin most browser/screenreader combinations. Admittedly, however, support for the
      \nelement is not yet universal. You may decide that screenreaders’ fallback experience — treating the list as standalone text nodes — isn’t sufficient for your use case, and instead opt for something like a
        \nuntil support improves.\nOkay, Okay, One Last Example!\nMy favorite example, the one that really takes the cake for me, is Dungeons & Dragons statblocks, which are really “Oops! All Name–Value Pairs!”\nNo, really: just how many candidates for
        \ns do you see in this statblock alone?\nI counted five possible description lists, personally. Here’s how I chose to mark this up:\nThis is just one way you could have opted to mark up that statblock.\nI love this as a demonstration because it really goes to show just how versatile the description list pattern can really be — the lists of ability scores (STR, DEX, and so forth) and attacks both look very different, and yet, the description list pattern can span them all.\nTakeaways\nLists of name–value pairs (or, in some cases, name–value groups) are a common pattern across the web, in part due to their versatility. HTML lets us mark up these lists with a combination of three elements:\n- The\n
        \n, or description list, element, which wraps the entire list of name–value pairs - The\n
        \n, or description term, element, which represents a name in our name–value pairs - The\n
        \n, or description detail, element, which represents a value in our name–value pairs\nAscribing semantics to patterns such as these gives our users’ devices the information they need to curate useful, usable experiences — oftentimes in ways that we as developers may not expect.\nTo learn more about description lists and what’s allowed or not allowed, I recommend the MDN docs on the
        \n, or going directly to the specs!\nFootnotes\nPrior to HTML5, this was called a definition list. This is because the\n
        \nwas originally only intended to represent glossaries of terms and their definitions. | Back to [1]Previously known as the definition term and definition detail elements respectively. | Back to [2]", "url": "https://wpnews.pro/news/on-the-dl-2021", "canonical_source": "https://benmyers.dev/blog/on-the-dl/", "published_at": "2026-05-23 13:03:43+00:00", "updated_at": "2026-05-23 18:34:58.360027+00:00", "lang": "en", "topics": ["developer-tools", "open-source"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/on-the-dl-2021", "markdown": "https://wpnews.pro/news/on-the-dl-2021.md", "text": "https://wpnews.pro/news/on-the-dl-2021.txt", "jsonld": "https://wpnews.pro/news/on-the-dl-2021.jsonld"}}