原生html提示方案有三种：用于可折叠交互，用于悬停提示，用于模态框；各自语义明确、无障碍友好，但需注意兼容性与使用限制。
用 <details></details> 和 <summary></summary> 实现点击展开提示
原生 HTML 就能做出带交互的提示框，不需要 JS —— <details></details> 是唯一被浏览器原生支持的可折叠交互容器。它默认收起，点击 <summary></summary> 触发展开/收起，语义清晰、无障碍友好、无需监听事件或操作 DOM。
常见错误是把 <summary></summary> 写成自闭合标签（如 <summary></summary>），这会导致内容不渲染；也有人试图给 <details></details> 加 onclick，纯属多余，反而干扰原生行为。
-
<summary></summary>必须是<details></details>的第一个子元素，且不能省略结束标签 - 默认展开需加
open属性：<details open></details> - Chrome/Firefox/Safari 均支持，IE 完全不支持（如需兼容 IE，此方案不可用）
- 内部可放任意 HTML，包括
<p></p>、<ul></ul>、甚至<pre class="brush:php;toolbar:false;"><code></code> 片段</pre>
用 title 属性实现悬停提示（tooltip）
title 是最轻量的提示方式，鼠标悬停触发，由浏览器原生渲染气泡，零配置、无样式控制、不支持换行或富文本。
容易被忽略的是：移动端上 title 基本无效（iOS Safari 不触发，Android Chrome 仅部分机型响应），且焦点键盘导航时无法访问（不符合 WCAG 2.1）。别把它当正式提示组件用，只适合辅助性、非关键信息。
- 适用于图标旁简短说明，如
<button title="删除此项">?</button> - 值中含换行符（
\n）在多数桌面浏览器会被忽略，不要依赖 - 若需键盘可访问，必须配合
aria-label或aria-describedby
用 <dialog></dialog> 实现模态提示框（需少量 JS 触发）
严格来说，<dialog></dialog> 本身是原生 HTML 元素，但“打开/关闭”动作需调用 show()、showModal() 或 close() 方法 —— 这部分无法绕过 JS。不过逻辑极简，不涉及状态管理或事件绑定，仍远轻于引入整个 UI 库。
典型翻车点：忘记调用 showModal() 而只用 show()，结果对话框不模态（背景仍可点击）；或未监听 close 事件导致关闭后状态不同步。
-
<dialog></dialog>默认隐藏，必须用 JS 显式打开 -
showModal()会禁用背景交互、聚焦到 dialog 内首个可聚焦元素 - 用户按
Esc或点击 backdrop 自动触发close事件，可借此清理状态 - Firefox 从 98+、Chrome 37+、Safari 15.4+ 支持；旧 Safari 需加 polyfill
为什么不用 <input type="range"> 或 <select></select> 模拟提示？
有人尝试用 <input type="range"> 的 title 或 <select></select> 的 option title 来“凑”提示，这是无效路径：前者 title 不显示，后者 option 的 title 在大多数浏览器中被忽略（尤其 Chrome 已明确不支持）。
更隐蔽的问题是语义错位：<select></select> 表达的是“选择”，不是“提示”；滥用会导致屏幕阅读器误读、自动化测试断言失败、未来维护者困惑。
- 不要为提示功能妥协语义结构
- 如果提示需随输入实时变化（如密码强度），那已超出原生 HTML 能力边界，JS 不可避免
- 原生方案的价值在于“够用即止”——明确知道什么能做、什么不能做，比硬套更省调试时间
真正难的不是写出一个能动的提示框，而是判断当前场景是否真需要它、以及用户会在什么上下文里看到它。比如移动端悬停提示根本不会出现，而 <details></details> 在窄屏下可能被误认为普通段落——这些细节比代码本身更影响体验。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
