惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

T
Threatpost
博客园 - 叶小钗
T
The Blog of Author Tim Ferriss
Recent Announcements
Recent Announcements
D
DataBreaches.Net
The Cloudflare Blog
阮一峰的网络日志
阮一峰的网络日志
罗磊的独立博客
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
N
Netflix TechBlog - Medium
Microsoft Azure Blog
Microsoft Azure Blog
Microsoft Security Blog
Microsoft Security Blog
B
Blog
U
Unit 42
有赞技术团队
有赞技术团队
博客园 - 聂微东
GbyAI
GbyAI
宝玉的分享
宝玉的分享
F
Full Disclosure
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
MyScale Blog
MyScale Blog
Jina AI
Jina AI
Martin Fowler
Martin Fowler
IT之家
IT之家
酷 壳 – CoolShell
酷 壳 – CoolShell
D
Docker
P
Proofpoint News Feed
A
About on SuperTechFans
I
InfoQ
博客园 - 【当耐特】
C
Check Point Blog
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
P
Privacy & Cybersecurity Law Blog
T
Threat Research - Cisco Blogs
Y
Y Combinator Blog
Project Zero
Project Zero
WordPress大学
WordPress大学
小众软件
小众软件
AWS News Blog
AWS News Blog
博客园 - 司徒正美
T
The Exploit Database - CXSecurity.com
L
LINUX DO - 热门话题
I
Intezer
Engineering at Meta
Engineering at Meta
C
CXSECURITY Database RSS Feed - CXSecurity.com
J
Java Code Geeks
T
Tenable Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Last Week in AI
Last Week in AI
C
CERT Recently Published Vulnerability Notes

Ben Myers

Tag, You’re It: Blog Questions 2025 Don’t Use aria-label on Static Text Elements Subtitles, Closed Captions, and Open Captions: What’s the Difference? Lost in Translation: Tips for Multilingual Web Accessibility Build a Blogroll with Eleventy I’m a Spotless Giraffe. How I Write Alt Text for Code Snippets on Social Media The Curious Case of “iff” and Overriding Screenreader Pronunciations The Web Needs a Native .visually-hidden Create Shareable Automatic Captions for Live Online Events with Web Captioner A First Look at the Websites and Software Applications Accessibility Act Bill Style with Stateful, Semantic Selectors How I Doubled My Lighthouse Performance Score in One Night How to Fix Your Low-Contrast Text Build a Twitch Chatbot for Sharing Your Content Using Algolia Search Ben’s Humane Guide to Technical Blogging Takeaways From “Adapting Comics for Blind and Low Vision Readers: A Roundtable Discussion” Takeaways From Axe-Con 2021 I Finally Understand Eleventy’s Data Cascade. RSS Readers: Yet Another Case for Semantic Markup Implement a Skip Link for Navigation-Heavy Sites aria-label, aria-labelledby, and aria-describedby: What’s the Difference? Out With The Old, In With The New Maintaining Focus Outlines for Windows High Contrast Mode Lexical and Dynamic Scope CSS Can Influence Screenreaders New Year, New Terminal: Alias Your Directories the Unix Way New Year, New Terminal: Alias Your Directories the Windows Way What Is ARIA? The Accessibility Tree How (Not) to Build a Button How Domino’s Could Topple the Accessible Web – Part 1: Public Accommodations
On the ‹dl›
Ben Myers · 2021-08-06 · via Ben Myers

Introduction

The <dl>, or description list, element is underrated.

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

Each 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 <dl> element.

So what does that look like?

The Anatomy of a Description List

I’ve been saying “<dl>,” when really, I’m talking about three separate elements: <dl>, <dt>, and <dd>.

We start with our <dl>. This is the description list,note 1 akin to using a <ul> for an unordered list or an <ol> for an ordered list.

<dl>

</dl>

Fancy.

Next up, we want to add a name–value pair. We’ll use a <dt>, short for description term, for the name, and we’ll use a <dd>, short for description detail, for the value.note 2

<dl>
	<dt>Title</dt>
	<dd>Designing with Web Standards</dd>
</dl>

To add another name–value pair to our list, we add another <dt> and <dd>:

<dl>
	<dt>Title</dt>
	<dd>Designing with Web Standards</dd>
	<dt>Publisher</dt>
	<dd>New Riders Pub; 3rd edition (October 19, 2009)</dd>
</dl>

But wait — what if I have a term that has multiple values? For instance, what if this book has multiple authors?

That’s fine! One <dt> can have multiple <dd>s:

<dl>
	<dt>Title</dt>
	<dd>Designing with Web Standards</dd>
	<dt>Author</dt>
	<dd>Jeffrey Zeldman</dd>
	<dd>Ethan Marcotte</dd>
	<dt>Publisher</dt>
	<dd>New Riders Pub; 3rd edition (October 19, 2009)</dd>
</dl>

There’s one last piece of the description list anatomy to look at for most basic use cases: what if I want to wrap a <dt> and its <dd>(s) for styling reasons?

In this case, the specs allow you to wrap a <dt> and its <dd>(s) in a <div>:

<dl>

	<div>
		<dt>Title</dt>
		<dd>Designing with Web Standards</dd>
	</div>

	<div>
		<dt>Author</dt>
		<dd>Jeffrey Zeldman</dd>
		<dd>Ethan Marcotte</dd>
	</div>

	<div>
		<dt>Publisher</dt>
		<dd>New Riders Pub; 3rd edition (October 19, 2009)</dd>
	</div>

</dl>

A wrapper <div> like this is the only element that can wrap those <dt>/<dd> groups.

And that’s it! That’s the anatomy of the description list, HTML's semantic way to mark up a list of name–value groups!

Why Do We Need Semantics For This Anyways?

Before we learned about the <dl>, <dt>, and <dd> elements, my team used to use nested <div>s for this pattern all the time. It looked a lot like:

<div class="book-details">
	<div class="book-details--item">
		<div class="book-details--label">
			Title
		</div>
		<div class="book-details--value">
			Designing with Web Standards
		</div>
	</div>
	<div class="book-details--item">
		<div class="book-details--label">
			Author
		</div>
		<div class="book-details--value">
			Jeffrey Zeldman
		</div>
		<div class="book-details--value">
			Ethan Marcotte
		</div>
	</div>
	<div class="book-details--item">
		<div class="book-details--label">
			Publisher
		</div>
		<div class="book-details--value">
			New Riders Pub; 3rd edition (October 19, 2009)
		</div>
	</div>
</div>

This 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 <div>s could get the job done?

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

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

  1. The screenreader could tell the user how many name–value groups are in the list.
  2. The screenreader could tell the user how far into the list they are.
  3. The screenreader could treat the list as one block that the user could skip over if they’re uninterested in it.

All of these could make the list more usable than a series of nested <div>s, which would treat each name and value in the list as nothing more than a standalone text node.

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

For what it’s worth, these screenreader experiences aren’t hypothetical — they’re benefits that screenreader users really get from using <dl> in most browser/screenreader combinations. Admittedly, however, support for the <dl> element 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 <ul> until support improves.

Okay, Okay, One Last Example!

My favorite example, the one that really takes the cake for me, is Dungeons & Dragons statblocks, which are really “Oops! All Name–Value Pairs!”

No, really: just how many candidates for <dl>s do you see in this statblock alone?

I counted five possible description lists, personally. Here’s how I chose to mark this up:

<div>
	<h1>Kobold</h1>
	<small>Small humanoid (kobold), lawful evil</small>

	<dl>
		<div>
			<dt>Armor Class</dt>
			<dd>12</dd>
		</div>
		<div>
			<dt>Hit Points</dt>
			<dd>5 (2d6 - 2)</dd>
		</div>
		<div>
			<dt>Speed</dt>
			<dd>30 ft.</dd>
		</div>
	</dl>

	<dl aria-label="Ability Scores">
		<div>
			<dt>STR</dt>
			<dd>7 (-2)</dd>
		</div>
		<div>
			<dt>DEX</dt>
			<dd>15 (+2)</dd>
		</div>
		<div>
			<dt>CON</dt>
			<dd>9 (-1)</dd>
		</div>
		<div>
			<dt>INT</dt>
			<dd>8 (-1)</dd>
		</div>
		<div>
			<dt>WIS</dt>
			<dd>7 (-2)</dd>
		</div>
		<div>
			<dt>CHA</dt>
			<dd>8 (–1)</dd>
		</div>
	</dl>

	<dl aria-label="Proficiencies">
		<div>
			<dt>Senses</dt>
			<dd>Darkvision 60 ft.</dd>
			<dd>Passive Perception 8</dd>
		</div>
		<div>
			<dt>Languages</dt>
			<dd>Common</dd>
			<dd>Draconic</dd>
		</div>
		<div>
			<dt>Challenge</dt>
			<dd>1/8 (25 XP)</dd>
		</div>
	</dl>

	<dl aria-label="Traits">
		<div>
			<dt>Sunlight Sensitivity</dt>
			<dd>
				While in sunlight, the kobold has disadvantage
				on attack rolls, as well as on Wisdom (Perception)
				checks that rely on sight.
			</dd>
		</div>
		<div>
			<dt>Pack Tactics</dt>
			<dd>
				The kobold has advantage on an attack roll against
				a creature if at least one of the kobold's allies
				is within 5 ft. of the creature and the ally
				isn't incapacitated.
			</dd>
		</div>
	</dl>

	<h2 id="actions">Actions</h2>
	<dl aria-labelledby="actions">
		<div>
			<dt>Dagger</dt>
			<dd>
				<i>Melee Weapon Attack:</i> +4 to hit, reach 5 ft.,
				one target. <i>Hit:</i> (1d4 + 2) piercing damage.
			</dd>
		</div>
		<div>
			<dt>Sling</dt>
			<dd>
				<i>Ranged Weapon Attack:</i> +4 to hit, reach 30/120 ft.,
				one target. <i>Hit</i>: (1d4 + 2) bludgeoning damage.
			</dd>
		</div>
	</dl>

</div>

This is just one way you could have opted to mark up that statblock.

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

Takeaways

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

  • The <dl>, or description list, element, which wraps the entire list of name–value pairs
  • The <dt>, or description term, element, which represents a name in our name–value pairs
  • The <dd>, or description detail, element, which represents a value in our name–value pairs

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

To learn more about description lists and what’s allowed or not allowed, I recommend the MDN docs on the <dl>, or going directly to the specs!


  1. 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. | Back to [1]

  2. Previously known as the definition term and definition detail elements respectively. | Back to [2]