<dl>에 관하여 (2021)

(benmyers.dev)

<dl> 은 이름–값 쌍 목록을 의미적으로 표현하는 HTML 요소로, 편의시설·청구 항목·기술 용어집 같은 UI 패턴에 적합함
설명 목록은 <dt> 이름과 <dd> 값을 <dl> 안에 배치하는 구조이며, 하나의 이름에 여러 값을 붙일 수도 있음
스타일링을 위해 관련 <dt>와 <dd>를 묶어야 할 때는 스펙상 <div> 래퍼만 그룹을 감쌀 수 있음
중첩 <div>만 쓰면 보조 기술이 목록 패턴을 인식하기 어렵지만, <dl>은 항목 수·현재 위치·목록 건너뛰기 같은 탐색 이점을 제공함
Dungeons & Dragons 스탯 블록처럼 서로 다른 형태의 수치·능력·행동 데이터도 설명 목록으로 나눌 수 있어 범용성이 잘 드러남

`<dl>`이 표현하는 패턴

<dl> 은 이름–값 쌍 목록을 표현하는 HTML 요소이며, 웹 UI에서 반복적으로 등장하는 패턴에 의미를 부여함
숙박 시설 편의시설, 월세의 개별 청구 항목, 기술 용어집처럼 이름과 값이 짝을 이루는 구조가 대표적인 후보가 됨
<dl>은 단독 요소가 아니라 <dl>, <dt>, <dd> 세 요소 조합으로 이름–값 그룹을 구성함
HTML5 이전에는 <dl>이 definition list로 불렸으며, 원래는 용어와 정의의 용어집을 표현하기 위한 요소였음

설명 목록의 기본 구조

<dl>, <dt>, <dd>
- <dl> 은 전체 설명 목록을 감싸며, <ul>이나 <ol>이 목록 전체를 감싸는 역할과 비슷함
- <dt> 는 설명 용어(description term)로 이름을 나타내고, <dd> 는 설명 세부정보(description detail)로 값을 나타냄
- <dt>와 <dd>도 이전에는 각각 definition term, definition detail로 알려져 있었음
- 기본 구조는 하나의 <dt> 뒤에 하나의 <dd>를 두는 형태임

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

여러 이름–값 쌍
- 같은 목록 안에 다른 이름–값 쌍을 추가하려면 새로운 <dt>와 <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>

하나의 이름에 여러 값
- 하나의 <dt>는 여러 개의 <dd> 값을 가질 수 있음
- 책의 저자가 여러 명인 경우처럼 하나의 이름에 여러 값이 붙는 구조를 직접 표현 가능함

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

스타일링을 위한 래퍼
- 관련 <dt>와 <dd>를 스타일링 목적으로 묶어야 할 때는 <div> 래퍼를 사용할 수 있음
- 스펙상 <dt>/<dd> 그룹을 감쌀 수 있는 래퍼 요소는 <div>뿐임
- 더 자세한 허용 구조와 제약은 MDN의 <dl> 문서나 HTML 스펙에서 확인 가능함

<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>
</dl>

의미론이 필요한 이유

이름–값 그룹은 중첩된 <div>만으로도 시각적으로 만들 수 있지만, 브라우저나 보조 기술이 이를 목록 패턴으로 인식하기 어려움
의미 요소 선택은 컴퓨터가 해당 패턴을 인식했을 때 사용자에게 실질적 이점이 생기는지를 기준으로 판단 가능함
<dl>을 쓰면 화면 읽기 프로그램 사용자는 이름–값 그룹 목록을 더 쉽게 탐색할 수 있음
- 목록 안의 이름–값 그룹 수를 알 수 있음
- 현재 목록에서 어느 위치에 있는지 파악할 수 있음
- 관심 없는 경우 목록 전체를 하나의 블록처럼 건너뛸 수 있음
중첩 <div> 구조에서는 각 이름과 값이 독립적인 텍스트 노드처럼 처리되지만, <dl>은 같은 정보에 구조적 의미를 부여함
이런 이점은 대부분의 브라우저/화면 읽기 프로그램 조합에서 <dl> 사용 시 실제로 제공됨
다만 <dl> 지원이 아직 보편적이지 않기 때문에, 독립 텍스트 노드로 처리되는 폴백 경험이 충분하지 않다면 지원이 개선될 때까지 <ul> 같은 다른 요소를 선택할 수도 있음

Dungeons & Dragons 스탯 블록 예시

Dungeons & Dragons의 스탯 블록은 이름–값 쌍이 많은 예시이며, 하나의 스탯 블록 안에서 여러 설명 목록 후보를 찾을 수 있음
Armor Class, Hit Points, Speed 같은 기본 수치, STR·DEX 같은 능력치, Senses·Languages·Challenge 같은 숙련 정보, Traits, Actions를 각각 설명 목록으로 나눌 수 있음
시각적으로 다른 능력치 목록과 공격 목록도 모두 설명 목록 패턴으로 표현 가능함
여러 설명 목록을 구분하거나 제목과 연결할 때는 aria-label과 aria-labelledby를 사용할 수 있음
이 마크업은 가능한 방법 중 하나이며, <dl> 패턴이 서로 다른 형태의 데이터 묶음에도 적용될 만큼 범용적임을 보여줌

▲

GN⁺ 5시간전 [-]

Lobste.rs 의견들

Markdown에 설명 목록(description list) 이 없는 게 아쉬움
- Pandoc 풍 Markdown은 적어도 두 가지 문법으로 설명 목록을 지원함
  다만 대부분 구현체는 지원하지 않는 게 맞음. 반면 조판 시스템/마크업 언어인 Typst는 / term: description처럼 설명 목록을 1급 문법으로 제공해서, - 글머리 목록이나 + 자동 번호 목록과도 잘 어울린다고 봄
- Hugo, Pandoc, GFM 같은 일부 구현체는 이런 형태를 지원하는 것으로 기억함
```
dt  
: dd  

dt  
: dd  
```
- Markdown은 HTML이 가진 걸 모두 가질 수 있음. HTML의 상위 집합이기 때문임
- https://www.djot.net/ 은 설명 목록을 지원함. 더 중요하게는 Djot이 HTML의 상위 집합이 아니어서, 비대한 HTML 지원 브라우저 밖에서도 쓸 수 있음
개인적으로 역대 상위 다섯 손가락 안에 드는 요소임
- <details>와 함께 확실히 상위권임. 이런 상호작용 요소가 더 많았으면 좋겠음
한 항목에 <dt>를 여러 개 둘 수도 있음. 사전식 목록에서 동의어 같은 걸 표현할 때 쓸 수 있음
CSS로 스타일링할 때는 인접 형제 선택자에 익숙해지는 게 좋음
참고: https://developer.mozilla.org/en-US/docs/…

답변달기

▲

GN⁺ 8시간전 [-]

Hacker News 의견들

이건 틀렸음: <dl>에는 대응되는 암시적 역할이 없지만 group, list, none, presentation 역할은 줄 수 있음 <https://w3c.github.io/html-aria/#el-dl>
aria-label은 암시적이든 명시적이든 호환되는 역할이 있는 요소에만 정의할 수 있고 <https://w3c.github.io/html-aria/#docconformance-naming>, aria-label은 대부분의 역할에서 허용되지만 <https://www.w3.org/TR/wai-aria-1.2/#aria-label> 여기서는 presentation과 none이 빠져서 group과 list만 남음
group은 어색하고 list는 받아들일 만하니, 결론은 aria-label을 빼거나 role="list"를 추가해야 함. 그러면 자식에는 role="listitem"도 필요함
글에서 놓친 건 <dt>가 하나만 오는 게 아니라 여러 개 연속될 수도 있다는 점임. 명세 예제가 좋음: https://html.spec.whatwg.org/multipage/grouping-content.html...
이건 이름-값 쌍이 아니라 이름-값 그룹임
- 이건 전혀 몰랐음. 궁금한데, <dt>와 <dd>를 감싸는 <div> 요소에 role="listitem"을 붙이겠음?
  role="listitem"은 <div>에 허용되는 것 같지만, 여러 <dt>가 함께 묶인 경우에는 정확하지 않아 보이고, <dt>가 원래 용어로 해석되는 방식까지 망가뜨릴지 잘 모르겠음
- 예전 HTML5 Doctor 글이 여전히 제일 마음에 듦: https://html5doctor.com/element-index/
여기서는 인기가 없겠지만, 시맨틱 HTML을 쓰려고 애쓰지 않으니 삶이 더 편해졌음. 설계가 그냥 별로임
<dl>을 쓰려고 할 때마다 결국 후회했음. 여러 단계의 래퍼가 필요하거나, 섹션 사이 구분선이 필요하거나, 아이콘이 필요하거나, 여러 키-값 쌍에 걸친 제목이 필요해졌기 때문임
어느 정도 유연성은 있지만, 표방하는 일반화된 개념을 실제로 감당하기에는 한참 부족함. 물론 <button>, <input>처럼 관찰 가능한 이득이 있는 대응 요소는 여전히 쓰지만, 데이터 모델에 딱 맞지도 않고 전부 덮어써야 한다면 실용적인 선택이 아님
사용의 99%가 API를 우회한다면 그건 아마 API의 잘못이라고 말하는 게 그렇게 논란일 일은 아님
- 스크린 리더를 매일 쓰는 입장에서 정말 동의함
  W3C가 이념적인 시맨틱 순수성 헛소리를 버리고 더 현실정치적으로 접근하면 모두에게 나을 것임. API가 의미론적으로 순수한지보다, 개발자가 무엇을 하고 싶어 하는지, 반대해도 어떤 꼼수를 쓸지, 그리고 그 일을 모두에게 최대한 이롭게 가능하게 만드는 방법을 봐야 함
  ARIA live region이 완벽한 예임. 개발자가 실제로 원하는 건 document.speakText임. 실제로 가진 건 페이지의 텍스트가 바뀔 때 이를 읽어주는 이상한 API임. 둘 사이를 이어야 하는데, 잘 구현해도 어렵고 해킹에 가까움. 그래도 적어도 live region 방식은 의미론적으로 순수한 HTML이긴 하겠지
- 그럼 CSS 잘못처럼 들림. display:contents로 래퍼를 제거할 수 있게 한 것처럼, 공통 조상이 있는 것처럼 요소를 묶는 방법도 도입해야 한다고 봄
  :wrap(dt, dt+dd) {border: solid 1px}
- HTTP에 대해서도 비슷하게 느낌. 이 프로토콜은 S3 같은 리소스 저장소에는 정말 잘 맞음. GET, PUT, DELETE가 모두 말이 되고, HTTP 상태 코드도 정확히 이 용도에 맞게 만들어져 있음
  하지만 웹 개발자로서 대부분은 리소스 저장소를 만들지 않음. 그런 건 매우 범용적이라 한 번 만들어 수백만 앱이 쓰면 됨. 누군가 HTTP와 상호작용하는 코드를 작성할 때 대부분은 원격 프로시저 호출을 하고 있음
  GraphQL, gRPC나 다른 원격 프로시저 호출 시스템을 쓰면 이런 걸 통째로 피함. 모든 걸 단일 엔드포인트에 POST로 보내고 추상화 계층을 하나 더 올려서, 애플리케이션에 매우 특화된 상황마다 4XX/5XX 오류를 반환하지 않아도 됨
  RFC 작성자들이 좀 과했던 건 분명함. 402 Payment Required, 407 Proxy Authentication Required, 508 Loop Detected는 특정 앱이나 배포 유형에 특화된 기능을 웹의 기반에 끼워 넣으려는 시도로 보임
  왜 RFC 작성자들의 구체적 필요는 웹의 기반에 구현되고, 내 필요는 어쩌다 겹치는 곳을 찾아서 앱 특화 요소를 전부 400 Bad Request나 500 Internal Server Error에 욱여넣어야 하는지 모르겠음. 웹 앱이 최소한 이상의 HTTP 상태 코드를 실제로 활용하는 걸 볼 때마다 눈을 굴리게 됨. 그런 건 애플리케이션 계층에 넣어야 함. 이 프로토콜은 당신을 위해 만들어진 게 아니라, 대부분 정적 자산을 제공하던 LAMP 스택 앱을 위해 만들어졌음
목록 역사 수업임. 아래 1985년 IBM 메인프레임 DCF/GML 매뉴얼을 보면, DL-DT-DD는 웹 이전부터 존재했음
40년 넘은 문서에는 Definition lists(DL) 외에도 Glossary lists(GL), Ordered lists(OL), Unordered lists(UL), Simple lists(SL)이 나옴
ibm :: 370 :: DCF :: SH35-0050-2 Document Composition Facility Generalized Markup Language Implementation Guide Rel 3 Mar85
https://archive.org/details/bitsavers_ibm370DCFSpositionFaci...
- GML은 1969년, SGML은 1970년대까지 거슬러 올라감. 내부에서는 BookMaster라는 걸 썼는데, HTML의 전신처럼 보이기도 했음
  <p> 대신 :p., <li> 대신 :li. 같은 식이었음. 1990~1991년쯤 TBL이 HTML과 HTTP를 개발하던 시기에, 하이퍼미디어에 초점을 둔 SGML 애플리케이션인 HyTime이라는 시도도 있었음. HTML이 꽤 빠르게 그것을 밀어냈음
  GML/SGML을 이끈 Charles Goldfarb는 https://en.wikipedia.org/wiki/Charles_Goldfarb 참고, SGML은 https://en.wikipedia.org/wiki/Standard_Generalized_Markup_La... 참고
- IBM Generalized Markup Language가 SGML(Standard Generalized Markup Language)로 발전했고, Tim Berners-Lee가 HTML 작업을 하던 CERN에서 SGML이 많이 쓰였던 것으로 알고 있음. HTML은 거기서 크게 파생됐음
  HTML에서 흥미로운 점은, 어떤 형태의 마크업 언어가 수십 년간 떠돌다가 Berners-Lee가 거기에 하이퍼링크를 추가했다는 것임
- 지금은 description list 아닌가?
세계 최초의 웹사이트는 <dl>을 많이 사용함
https://info.cern.ch/hypertext/WWW/TheProject.html
https://info.cern.ch/ 실제 최초 웹사이트에 대한 맥락과 방향을 주는 일종의 랜딩 페이지임
네이티브 GUI 툴킷은 다 죽었는데, 이제는 사람들이 HTML 요소 하나를 두고 긴 에세이를 쓸 수 있음. 이게 발전인가 싶음
HTML5 이전에는 이걸 definition list라고 불렀고, 원래 <dl>은 용어와 정의로 된 glossary만 표현하려고 했다는 걸 이제 알았음. 10년 동안 이름을 잘못 부르고 있었네
- b가 이제는 “bring attention to”라니. 참나
- 혼자가 아님. 이번 주에 이걸 두 번째 봤고, 처음에는 실수인 줄 알았음
- definition list에서 이름이 바뀌었다는 걸 이제 알았음
- HTML5가 표준화된 연도를 확인하고 싶지 않음. 10년도 더 됐을 가능성이 커서 ;)
좋은 글임. 아주 사소한 트집을 잡자면, small 요소는 부제목에 쓰면 안 되고, 그 용도에는 hgroup 요소를 써야 함
small 요소는 작은 글씨 같은 부가 코멘트를 나타냄. 작은 글씨에는 보통 면책 조항, 주의 사항, 법적 제한, 저작권이 들어감. 출처 표기나 라이선스 요구사항 충족에도 가끔 쓰임
(https://html.spec.whatwg.org/multipage/text-level-semantics....)
스크린 리더가 <dl>을 얼마나 잘 지원하는지에 대한 유용한 메모가 있음: https://adrianroselli.com/2025/01/updated-brief-note-on-desc...
DnD 능력치 시트의 마지막 예제를 보니 <dl>을 중첩해도 합법인지 궁금해짐
예를 들면 Actions ... 같은 식으로 할 수 있나?
- 가능함. <dd> 안에는 모든 플로 콘텐츠가 허용됨
  https://html.spec.whatwg.org/#the-dd-element
  https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
<dl>을 좋아함. 적어도 과거에는 테이블이 <dl>처럼 오용되는 경우가 더 많았던 것 같고, 테이블 마크업의 불편함은 div 여럿보다 더 심함
- 불필요한 닫는 태그를 생략하면 그렇게 불편하지 않음
  first
  second
  what
  ever
  어떤 Markdown 테이블 문법보다 더 단순하고 깔끔하다고 봄
- 맞음. 하지만 테이블이 <dl> 흉내를 내도록 강요된 건 테이블 오용 중에서도 훨씬 나은 편이었음
- 늘 <dl>을 테이블의 단일 행처럼 생각했음

답변달기

<dl>에 관하여 (2021)

<dl>이 표현하는 패턴

설명 목록의 기본 구조

<dl>, <dt>, <dd>

여러 이름–값 쌍

하나의 이름에 여러 값

스타일링을 위한 래퍼

의미론이 필요한 이유

Dungeons & Dragons 스탯 블록 예시

함께 보면 좋은 글 β

댓글과 토론

Lobste.rs 의견들

Hacker News 의견들

`<dl>`이 표현하는 패턴

`<dl>`, `<dt>`, `<dd>`