必须在缩写词首次出现且需同时表明“是缩写”和“正式定义”时，才用缩写；abbr须带自然语言全称title，dfn不可加title，顺序不可颠倒。

abbr 和 dfn 可以嵌套，但仅在一种明确场景下合法且有意义：缩写词首次被定义时。其他情况嵌套属于语义错误，反而损害可访问性与 SEO。

什么时候必须用 dfn 套 abbr

只有当一个缩写词在文档中第一次出现，且你同时想表达「这是个缩写」+「此处正式引入并定义它」两个意图时，才应写成 API。

• 必须满足：该缩写此前未在页面中出现过（否则不是“首次定义”）
• abbr 必须带 title 属性，内容为完整、自然语言的全称（不能是“参见附录”之类）
• dfn 本身不应加 title —— 否则会覆盖 abbr 的提示，屏幕阅读器可能只读外层 title
• 嵌套顺序只能是 ...；反过来或并列都无效

为什么不能用 dfn 单独解释缩写

dfn 的语义是“此处正在定义一个术语”，不是“此处展开一个缩写”。浏览器和辅助技术不会把 API 当作缩写处理。

• 没有 abbr 标签，title 不会被识别为缩写展开，SEO 和语音朗读都丢失关键信息
• 移动端无 hover，title 在 dfn 上几乎不可见，等于没提供解释
• 若用户禁用 tooltip 或使用键盘导航，该解释完全不可达

常见错误写法及后果

以下写法看似能“hover 出说明”，实则破坏语义结构：

• 我们调用 API 接口

  → 缺少 abbr，缩写语义丢失

• 前端使用 CSS 和 组件化

  

  使用华数设计生成高保真HTML原型、演示文稿、动画和设计评审

  使用经过文档化的设计技能，从真实的品牌或项目背景中生成HTML原生原型、幻灯片、动态演示、可视化图表和评审流程。

  下载
  → dfn 用在非首次定义处，语义冗余

• JS 是一门脚本语言

  → abbr 的 title 写成了简称而非全称，违反规范

这些写法会让屏幕阅读器误读、搜索引擎无法准确提取术语关系、键盘用户错过关键解释。

真正需要手动补救的兼容性盲区

即使语义写对了，abbr + dfn 嵌套在实际交付中仍有两处必须人工干预：

• 所有主流浏览器默认不显示 abbr[title] 的提示框（尤其 Safari 移动版），必须额外加 CSS 规则如 abbr[title]:after { content: " (" attr(title) ")"; } 才能让全称可见
• dfn 默认斜体（Chrome/Firefox），但 Safari 不斜体，若靠样式区分定义项，需统一重置或补充视觉标记（如小字号上标、浅色底纹）

别指望浏览器自动做好这件事——语义正确只是起点，可见性补救才是用户真正能“看到解释”的关键一步。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！