dfn标签用于标记术语首次出现时的定义，而非单纯实现斜体效果；必须紧邻自然语言定义句，包裹被定义的词本身，配合title或aria-describedby提升可访问性。
dfn标签不是用来加斜体的
浏览器默认给 dfn 加 font-style: italic，但这只是历史遗留样式，不是它的目的。你看到的斜体只是副作用，不是功能——就像 strong 默认加粗，但重点是语义上的“强重要性”，不是为了变粗。如果只想要斜体效果，用 em 或 CSS 更直接、更可控。
常见错误现象：<dfn>API</dfn> 单独出现，前后没有定义句；或者在文档中反复给同一个词套 dfn（比如第二、第三次出现还加）。这会让屏幕阅读器误判“这个词又被定义了一次”，破坏语义连贯性。
实操建议：
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 只在术语**首次出现且紧邻定义语句**时使用
dfn - 定义语句必须是自然语言描述，不能是空话或重复术语本身（如
<dfn>HTTP</dfn> HTTP 是……） - 避免仅靠视觉判断是否该用：打开开发者工具，删掉所有样式，看是否还能清晰识别“哪句在定义哪个词”
dfn必须包裹被定义的术语本身
dfn 的内容必须是那个被定义的词或短语，不能是解释、不能是整段话、不能嵌套其他 dfn。HTML 规范明确说它是 “the term being defined”，不是 “the definition”。把它当成一个锚点标记，而不是容器。
立即学习“前端免费学习笔记（深入）”；
常见错误现象：<dfn>一种用于描述网页结构的标记语言</dfn> —— 这里被包裹的是解释，不是术语；<dfn><dfn>HTML</dfn></dfn> —— 嵌套导致解析失败，辅助技术可能跳过或报错。
实操建议：
- 写完定义句后，反向检查：把
dfn标签去掉，剩下句子是否仍通顺？被定义的词是否还在原位？ - 术语若含空格或标点（如
Web API、CSS-in-JS），整个字符串必须完整包裹在一对dfn中，不可拆分 - 不要用
dfn包裹带链接的术语（如<a href="..."><dfn>DOM</dfn></a>），语义冲突；应先定义，再链接，或用aria-describedby关联
如何让 dfn 真正被辅助技术识别
光有 dfn 标签远远不够。主流屏幕阅读器（NVDA、VoiceOver）对 dfn 的支持依赖于显式线索：要么靠 title 属性，要么靠 id + aria-describedby，否则它很可能被当成普通文本跳过。
性能与兼容性影响：纯靠自然邻近结构（如定义句紧跟其后）最轻量，但可访问性保障弱；加 title 兼容性好、实现简单，但长度受限（通常截断在 255 字符内）；用 aria-describedby 最灵活，但需确保目标元素存在且可访问（不能 display: none 或 aria-hidden="true"）。
实操建议：
- 短定义优先用
title：<dfn title="客户端执行的脚本语言">JavaScript</dfn> - 长解释或跨结构定义，用
id+aria-describedby：<dfn id="semantics" aria-describedby="def-semantics">语义化</dfn>，再配<p id="def-semantics">指使用具有明确含义的 HTML 元素……</p> - 避免同时用
title和aria-describedby，部分读屏会重复播报
dfn 和 abbr、dl/dd 的边界在哪
abbr 只负责缩写展开（如 <abbr title="Cascading Style Sheets">CSS</abbr>），不承担“定义新概念”的责任；dl/dd 是结构化术语表容器，适合集中罗列，但单个 dfn 必须出现在定义上下文中，不能脱离语句独立存在。
容易踩的坑：在 dl 的 dt 里用 dfn 是合理用法（<dt><dfn>URI</dfn></dt>），但如果在 dd 里又套一层 dfn，就变成“定义一个定义”，逻辑坍塌。
实操建议：
- 日常行文中的首次定义，用
dfn+ 邻近句子 - 需要术语索引或独立词条页，用
dl，并在dt内用dfn强化入口语义 - 遇到缩写+新概念双重身份（如 “SPA” 既是 Single Page Application 缩写，又是前端架构模式），先用
abbr展开缩写，再用dfn定义概念，顺序不能颠倒
真正难的不是怎么写 dfn，而是判断“这句话算不算一次有效定义”。它要求你对术语的引入节奏、读者认知路径有预判——多数人卡在这一步，而不是语法上写错标签。
