dl 标签仅适用于人类可读的术语–解释型文档，如 API 文档中的参数说明，每项须严格遵循一个 dt（术语名）配一个 dd（解释），禁止混入非 dt/dd 元素或当作键值对容器使用。
dl不是键值对容器，别当用
HTML 的 dl 标签不表示“键值对”，它只表达「术语–解释」的语义关系。强行把配置项、API 参数、JSON 字段当“键”塞进 dt，再把值塞进 dd，容易导致结构松散、可访问性断裂——屏幕阅读器会按「术语→描述→术语→描述」线性播报，中间若夹杂多个 dd 或嵌套结构，逻辑就断了。
常见错误现象：
-
dt 里写 maxRetries，dd 里直接放 {"type": "number", "default": 3}
- 用
dl 包裹整个配置区块，内部混入 p、div、甚至 table —— dl 只接受 dt 和 dd 作为直接子元素，其他标签会触发隐式闭合，浏览器自动修正后 DOM 结构不可控
属性列表该用 dl 的唯一合理场景
只有当你在写**人类可读的文档型属性说明**（比如 API 文档、组件 props 表、CLI 命令帮助页），且每项都满足「一个名称 + 一段解释」时，dl 才是正确选择。它比表格更轻量，比段落更结构化，还自带无障碍语义支持。
实操建议：
- 每个配置项必须有明确的术语名：用
dt 写参数名（如 timeoutMs），不能写“超时时间”这种中文描述——那是 dd 的事
-
dd 里可包含多段文字、code 片段、甚至内联 em 或 strong，但避免嵌套块级元素（如 p、ul）；真需要分点说明，改用 ul 包在 dd 内
- 默认样式下
dd 仅靠 margin-left 缩进，现代 CSS 重置常清零它，所以务必加一句：dd { margin-inline-start: 1.5em; }（推荐用逻辑属性，兼容 RTL）
为什么不用 table 或 div.grid 替代 dl
有人图省事用 table 列两栏，或用 div + CSS Grid 模拟术语/值布局，但这牺牲了语义和可访问性。搜索引擎和辅助技术不会把 table 的第一列自动识别为“参数名”，也不会把 div 的左栏当作可导航的术语锚点。
htmlppt.skill
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
下载
关键差异：
-
table 暗示行列数据关系（如 CSV 导入结果），不适合描述性内容
-
div + Grid 完全无语义，需手动加 role="definitionlist" 和 aria-labelledby，维护成本高、易遗漏
-
dl 在所有主流浏览器中被原生支持，dt 自动获得 role="term"，dd 对应 role="definition"，无需额外标注
响应式排版中 dl 的实际处理方式
桌面端想左右并排、移动端堆叠，别硬调 float 或 display: flex——dl 的语义流本就是垂直的，强行水平拉伸反而让阅读顺序错乱。
推荐做法：
- 基础层保持语义流：
dt + dd 垂直堆叠，确保窄屏下可读
- 中宽屏（≥768px）用
display: grid 控制视觉布局：dl { display: grid; grid-template-columns: max-content 1fr; column-gap: 1em; }，再用 dt { grid-column: 1; }、dd { grid-column: 2; } 显式定位
- 避免给
dt 设固定宽度——术语长度差异大，max-content 能自适应
真正难处理的是嵌套定义（比如某个参数的值本身是个对象，还要展开字段说明）。这时不要在同一个 dl 里递归套 dl，而应在 dd 内新建独立 dl，并用 aria-label 注明上下文，例如：
HTML 的 dl 标签不表示“键值对”，它只表达「术语–解释」的语义关系。强行把配置项、API 参数、JSON 字段当“键”塞进 dt，再把值塞进 dd，容易导致结构松散、可访问性断裂——屏幕阅读器会按「术语→描述→术语→描述」线性播报，中间若夹杂多个 dd 或嵌套结构，逻辑就断了。
常见错误现象：
-
dt里写maxRetries，dd里直接放{"type": "number", "default": 3} - 用
dl包裹整个配置区块，内部混入p、div、甚至table——dl只接受dt和dd作为直接子元素，其他标签会触发隐式闭合，浏览器自动修正后 DOM 结构不可控
属性列表该用 dl 的唯一合理场景
只有当你在写**人类可读的文档型属性说明**（比如 API 文档、组件 props 表、CLI 命令帮助页），且每项都满足「一个名称 + 一段解释」时，dl 才是正确选择。它比表格更轻量，比段落更结构化，还自带无障碍语义支持。
实操建议：
- 每个配置项必须有明确的术语名：用
dt写参数名（如timeoutMs），不能写“超时时间”这种中文描述——那是dd的事 -
dd里可包含多段文字、code片段、甚至内联em或strong，但避免嵌套块级元素（如p、ul）；真需要分点说明，改用ul包在dd内 - 默认样式下
dd仅靠margin-left缩进，现代 CSS 重置常清零它，所以务必加一句：dd { margin-inline-start: 1.5em; }（推荐用逻辑属性，兼容 RTL）
为什么不用 table 或 div.grid 替代 dl
有人图省事用 table 列两栏，或用 div + CSS Grid 模拟术语/值布局，但这牺牲了语义和可访问性。搜索引擎和辅助技术不会把 table 的第一列自动识别为“参数名”，也不会把 div 的左栏当作可导航的术语锚点。
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
关键差异：
-
table暗示行列数据关系（如 CSV 导入结果），不适合描述性内容 -
div+ Grid 完全无语义，需手动加role="definitionlist"和aria-labelledby，维护成本高、易遗漏 -
dl在所有主流浏览器中被原生支持，dt自动获得role="term"，dd对应role="definition"，无需额外标注
响应式排版中 dl 的实际处理方式
桌面端想左右并排、移动端堆叠，别硬调 float 或 display: flex——dl 的语义流本就是垂直的，强行水平拉伸反而让阅读顺序错乱。
推荐做法：
- 基础层保持语义流：
dt+dd垂直堆叠，确保窄屏下可读 - 中宽屏（≥768px）用
display: grid控制视觉布局：dl { display: grid; grid-template-columns: max-content 1fr; column-gap: 1em; }，再用dt { grid-column: 1; }、dd { grid-column: 2; }显式定位 - 避免给
dt设固定宽度——术语长度差异大，max-content能自适应
真正难处理的是嵌套定义（比如某个参数的值本身是个对象，还要展开字段说明）。这时不要在同一个 dl 里递归套 dl，而应在 dd 内新建独立 dl，并用 aria-label 注明上下文，例如：
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
