- `` は、名前と値のペアの一覧を意味的に表現する HTML 要素で、宿泊施設の設備、請求項目、技術用語集のような UI パターンに適している
- 説明リストは
名前** と ** 値 を `` の中に配置する構造で、1 つの名前に複数の値を対応づけることもできる
- スタイリングのために関連する
と をまとめる必要がある場合、仕様上は `` ラッパー だけがグループを囲める
- 入れ子の
だけでもリストパターンは作れるが、支援技術はそのパターンを認識しにくく、 は項目数、現在位置、リストのスキップといったナビゲーション上の利点を提供する
- Dungeons & Dragons のステータスブロックのように、異なる形式の数値・能力・行動データも説明リストとして分割でき、汎用性の高さがよく分かる
`` が表現するパターン
- `` は、名前と値のペアの一覧を表現する HTML 要素であり、Web UI で繰り返し現れるパターンに意味を与える
- 宿泊施設の設備、家賃の個別請求項目、技術用語集のように、名前と値 が対になる構造が代表的な候補になる
は単独の要素ではなく、、、 の 3 要素の組み合わせで名前と値のグループを構成する- HTML5 以前、`` は definition list と呼ばれており、もともとは用語と定義の用語集を表現するための要素だった
説明リストの基本構造
-
、、``
- **
** は説明リスト全体を包み、 や `` がリスト全体を囲むのと似た役割を持つ
** は説明語句 (description term) として名前を表し、** は説明詳細 (description detail) として値を表すと も以前はそれぞれ definition term、definition detail として知られていた- 基本構造は 1 つの
の後ろに 1 つの を置く形である
Title
Designing with Web Standards
-
複数の名前と値のペア
- 同じリストの中に別の名前と値のペアを追加するには、新しい
と を続けて配置する
Title
Designing with Web Standards
Publisher
New Riders Pub; 3rd edition (October 19, 2009)
-
1 つの名前に複数の値
- 1 つの
は複数の ** 値** を持てる
- 本に著者が複数いる場合のように、1 つの名前に複数の値が付く構造をそのまま表現できる
Title
Designing with Web Standards
Author
Jeffrey Zeldman
Ethan Marcotte
Publisher
New Riders Pub; 3rd edition (October 19, 2009)
-
スタイリングのためのラッパー
- 関連する
と をスタイリング目的でまとめたい場合は、`` ラッパー を使える
- 仕様上、
/ グループを囲めるラッパー要素は `` のみである
- より詳しい許可構造と制約は MDN の `` ドキュメント や HTML 仕様 で確認できる
Title
Designing with Web Standards
Author
Jeffrey Zeldman
Ethan Marcotte
セマンティクスが必要な理由
- 名前と値のグループは、入れ子の `` だけでも視覚的には作れるが、ブラウザや支援技術がそれを リストパターン として認識するのは難しい
- セマンティックな要素の選択は、コンピュータがそのパターンを認識したときに、利用者へ実質的な利点が生まれるかどうかを基準に判断できる
- `` を使うと、スクリーンリーダー利用者は名前と値のグループの一覧をより簡単に移動できる
- リスト内の 名前と値のグループ数 を把握できる
- 現在リストのどの位置にいるかを把握できる
- 関心がなければリスト全体を 1 つのブロックのようにスキップできる
- 入れ子の
構造では各名前と値が独立したテキストノードのように扱われるが、 は同じ情報に 構造的な意味 を与える
- こうした利点は、大半のブラウザ／スクリーンリーダーの組み合わせ で `` を使った場合に実際に提供される
- ただし
のサポートはまだ十分に一般的とはいえないため、独立したテキストノードとして扱われるフォールバック体験で不十分なら、サポートが改善されるまで のような別の要素を選ぶこともできる
Dungeons & Dragons ステータスブロックの例
- Dungeons & Dragons のステータスブロックは、名前と値のペアが多い例であり、1 つのステータスブロックの中に複数の説明リスト候補を見つけられる
- Armor Class、Hit Points、Speed のような基本数値、STR・DEX のような能力値、Senses・Languages・Challenge のような習熟情報、Traits、Actions をそれぞれ説明リストとして分けられる
- 視覚的に異なる能力値リストと攻撃リストも、どちらも 説明リストパターン として表現できる
- 複数の説明リストを区別したり、見出しと関連付けたりする際には
aria-label と aria-labelledby を使える
- このマークアップは可能な方法の 1 つであり、`` パターンが異なる形のデータのまとまりにも適用できるほど 汎用的 であることを示している
2件のコメント
Lobste.rsの意見
ただし、ほとんどの実装が対応していないのはその通り。一方で組版システム／マークアップ言語のTypstは、
/ term: descriptionのように説明リストを第一級の構文として提供していて、-の箇条書きリストや+の自動番号付きリストとも相性が良いと思う<details>と並んで間違いなく上位。こういうインタラクティブ要素がもっと増えてほしい<dt>を複数置くこともできる。辞書形式のリストで同義語のようなものを表現するときに使えるCSSでスタイリングするときは隣接兄弟セレクタに慣れておくとよい
参考: https://developer.mozilla.org/en-US/docs/…
Hacker Newsの意見
これは間違っている:
には対応する暗黙の役割はないが、`group`、`list`、`none`、`presentation` の役割は与えられる `aria-label` は、暗黙的または明示的に互換性のある役割を持つ要素に対してのみ定義でき、`aria-label` はほとんどの役割で許可されているが、ここでは `presentation` と `none` が外れるので、`group` と `list` だけが残る `group` は不自然で、`list` は許容できるので、結論は **aria-label を外すか** `role="list"` を追加すべきということになる。そうすると子には `role="listitem"` も必要になる 記事で見落としているのは、は 1 つだけ来るのではなく、複数が連続することもあるという点だ。仕様の例がよい: https://html.spec.whatwg.org/multipage/grouping-content.html... これは名前と値の組ではなく、名前と値のグループだとを包む要素に `role="listitem"` を付けるつもり？ `role="listitem"` はでは許可されているようだが、複数のが一緒に束ねられる場合には正確ではないように見えるし、が本来用語として解釈される挙動まで壊してしまうのかはよく分からないここでは不人気だろうが、セマンティック HTML を使おうと頑張らなくなってから人生が楽になった。設計が単純によくない
を使おうとするたび、結局後悔した。何層ものラッパーが必要になったり、セクション間の区切り線が必要になったり、アイコンが必要になったり、複数のキーと値の組にまたがる見出しが必要になったりするからだ ある程度の柔軟性はあるが、標榜している一般化された概念を実際に扱うには到底足りない。もちろん, `` のように観測可能な利点がある対応要素は今でも使うが、データモデルにぴったり合うわけでもなく、全面的に上書きしなければならないなら実用的な選択ではない 利用の 99% が API を回避することなら、それはたぶん API の側が悪い と言うのは、そこまで物議を醸す話ではないdocument.speakTextだ。実際にあるのは、ページのテキストが変わったときにそれを読み上げる奇妙な API だ。その間を埋めなければならないが、うまく実装しても難しく、ほとんどハックに近い。それでも少なくとも live region 方式は意味論的に純粋な HTML ではあるのだろうdisplay:contentsでラッパーを消せるようにしたように、共通の祖先があるかのように要素をグループ化する方法も導入すべきだと思う:wrap(dt, dt+dd) {border: solid 1px}402 Payment Required、407 Proxy Authentication Required、508 Loop Detectedは、特定のアプリやデプロイ形態に特化した機能を Web の土台に押し込もうとしたように見える なぜ RFC 執筆者の具体的な必要は Web の土台に実装され、私の必要はたまたま重なる部分を探して、アプリ特化の要素を全部400 Bad Requestや500 Internal Server Errorに押し込めなければならないのか分からない。Web アプリが最低限以上の HTTP ステータスコードを実際に活用しているのを見るたびに目を回したくなる。そういうものはアプリケーション層に置くべきだ。このプロトコルはあなたのために作られたのではなく、主に静的アセットを配信していた LAMP スタックのアプリ のために作られたのだリストの歴史の授業だ。下の 1985 年の IBM メインフレーム DCF/GML マニュアルを見ると、DL-DT-DD は Web 以前から存在していた 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...
:p.、`の代わりに: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... を参照世界初の Web サイトでは `` が多用されている https://info.cern.ch/hypertext/WWW/TheProject.html https://info.cern.ch/ は、本物の最初の Web サイトに関する文脈と案内を与える一種のランディングページだ
ネイティブ GUI ツールキットはみんな死んだのに、今では人々が HTML 要素 1 つ をめぐって長文のエッセイを書ける。これが進歩なのだろうか
HTML5 以前はこれを definition list と呼んでいて、もともと `` は用語と定義からなる glossary だけを表すものだったと、今になって知った。10 年間ずっと名前を間違えていたよ
bが今では「bring attention to」だなんて。まったくいい記事だ。ごく些細な難癖をつけるなら、
small要素はサブタイトルに使うべきではなく、その用途にはhgroup要素を使うべきだsmall要素は、小さな文字の補足コメントのようなものを表す。小さな文字には通常、免責事項、注意事項、法的制限、著作権が入る。帰属表示やライセンス要件を満たすために使われることもある (https://html.spec.whatwg.org/multipage/text-level-semantics....)スクリーンリーダーが `` をどれくらいうまくサポートしているかについての有用なメモがある: https://adrianroselli.com/2025/01/updated-brief-note-on-desc...
DnD 能力値シートの最後の例を見て、`` を ネスト しても合法なのか気になった たとえば
Actions ...のようにできる？は好きだ。少なくとも昔は、テーブルがのように誤用されるケースのほうが多かった気がするし、テーブルマークアップの不便さはdivをいくつも並べるよりひどいfirstsecondwhateverどんな Markdown テーブル構文 よりも単純で整っていると思う