abbr 的 title 属性必须非空且语义准确，仅支持标准全称；首次出现缩写应在正文中写出全称+缩写，并用 abbr 包裹缩写，以保障可访问性、seo 和所有用户理解。
abbr 的 title 属性必须非空且语义准确，否则等于没写
浏览器和屏幕阅读器只认 title 属性值——不是标签本身，也不是 CSS 或 JS。空字符串 title=""、纯空格 title=" "、或含 HTML 标签的值（如 title="<em>CSS</em>"）都会被忽略，abbr 退化为普通 span。
正确写法只有一个要求：用标准全称，不加括号、不加“即”“也就是”等冗余词。例如：
-
<abbr title="Cascading Style Sheets">CSS</abbr>✅ -
<abbr title="JavaScript Object Notation">JSON</abbr>✅ -
<abbr title="World Health Organization">WHO</abbr>✅ -
<abbr title="API (Application Programming Interface)">API</abbr>❌ 括号和缩写重复 -
<abbr title="that is">i.e.</abbr>❌ 非正式缩写，通常无需abbr
桌面端悬停提示不可靠，别当成 UI 功能来依赖
Chrome 和 Edge 自 2025 年起默认禁用 title 的悬停渲染（为减少干扰和隐私风险），Firefox 仍保留但延迟高、易消失；Safari macOS 版本虽显示，但内容截断严重（超 60 字符就省略）。更关键的是：
- 移动端 Safari 完全不触发
title提示，长按最多闪现半秒 - Android Chrome 基本忽略
title，尤其在 WebView 或 PWA 中 - 键盘用户无法通过 Tab 进入或聚焦
abbr，title内容不可访问 - 高对比度模式下，系统级 tooltip 常被隐藏
换句话说：title 是语义信号，不是 UI 组件。你写对了，Lighthouse 才不会报 “abbr missing description”，但用户能不能看到，得看运气。
缩写首次出现时，正文里写全称比靠 title 更有效
WCAG 明确建议：对读者可能陌生的缩写，首次出现应自然写出全称 + 缩写，再用 abbr 包裹缩写本身。这不是可选项，而是可访问性刚需。
比如这样写：
<p>Application Programming Interface (<abbr title="Application Programming Interface">API</abbr>) enables communication between software systems.</p>
好处是三重保障：
- 所有用户第一眼看到含义，无需悬停或辅助技术
- 屏幕阅读器朗读时顺序合理（先全称后缩写），避免重复感
- 搜索引擎更容易理解上下文，提升 SEO 相关性
后续再出现 API，才单独用 <abbr title="Application Programming Interface">API</abbr> 即可。
想真正控制提示样式和行为？必须绕开 title，用 data-* + JS 实现
原生 title 不支持换行、背景色、箭头、动画、移动端 tap 触发，也不能加 role 或 aria-hidden。真要稳定交付视觉提示，得放弃它：
- 用
data-full存全称：<span class="tooltip-trigger" data-full="Cascading Style Sheets">CSS</span> - 监听
mouseenter（不用onmouseover，避免冒泡）和focus（覆盖键盘用户） - 动态创建带
role="tooltip"和id的 DOM 节点，用getBoundingClientRect()定位 - 每次显示前清空旧内容并重置
aria-hidden="false"，否则读屏器会复用上一个缩写的全称
最常被忽略的一点：提示层 DOM 必须在隐藏时彻底移除（不是 display: none），否则焦点管理会混乱，键盘用户可能卡在不可见的 tooltip 上。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
