用 <details> 和 <summary> 可实现纯 HTML 的“隐藏答案，点击揭晓”效果：<details><summary>点击查看答案</summary><p>正确答案是：document.getElementById()</p></details>。

怎么用 HTML 实现“隐藏答案，点击揭晓”效果

纯 HTML 无法实现交互式隐藏/显示，必须配合 details 元素或少量 JS。最轻量、语义正确、无需 JS 的方案是 details + summary，但要注意它不支持自定义展开动画和部分老浏览器。

• details 是原生可折叠容器，summary 是默认可见的标题行，点击后展开内部内容（即“答案”）
• 所有现代浏览器都支持，IE 完全不支持 —— 如果需兼容 IE，必须用 JS 控制 display 或 hidden 属性
• 不能用 div + hidden 属性模拟，因为 hidden 是静态属性，不会响应点击
• 别给 summary 加 onclick，会干扰原生展开逻辑；如需额外行为（比如埋点），用 addEventListener('toggle')

<details>
  <summary>点击查看答案</summary>
  <p>正确答案是：<pre class="brush:php;toolbar:false;">document.getElementById()</code></p>
</details>

为什么 details 比 <code>aria-hidden + JS 更合适

很多人想用 ARIA 属性手动控制显隐，结果写出一堆冗余 JS 和易错状态管理。而 details 自带状态（open 属性）、键盘可访问（空格/回车触发）、屏幕阅读器自动识别，语义清晰且零配置。

• aria-hidden="true" 只影响辅助技术，对 CSS 渲染无作用，还得额外写 CSS（如 visibility: hidden）才能真正隐藏
• 手写 JS 切换 display: none/block 容易遗漏焦点管理，导致键盘用户卡在不可见区域
• details[open] 是真实 DOM 状态，CSS 可直接用 details[open] summary::after 改图标，不用监听事件

常见错误：用 input type="checkbox" 模拟展开

这种“伪交互”方案看似不用 JS，实则问题集中：标签关联难、焦点跳转异常、移动端点击穿透、无法被屏幕阅读器识别为可展开控件。

anything-to-html

将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。

下载

• 必须用 for 和 id 严格配对，否则点击文字不触发勾选
• 勾选框本身会占据 tab 键顺序，用户可能意外聚焦到一个看不见的 checkbox 上
• 安卓 WebView 和部分 iOS 版本中，label 包裹 input 后点击 summary 区域可能失效
• 没有 toggle 事件，无法得知何时展开/收起，后续逻辑（如统计曝光）难以接入

如果必须兼容 IE，最小可行 JS 方案

只补足 IE 缺失的交互能力，其他逻辑全部交给 HTML/CSS。核心是监听点击、切换 data-open 属性、用 CSS 控制显隐，避免操作 innerHTML 或重复绑定。

立即学习“前端免费学习笔记（深入）”；

• 给容器加 data-accordion 标识，避免污染全局命名
• 用 element.dataset.open = 'true' 而非 setAttribute，更安全
• CSS 写成 [data-open="true"] .answer，不要用 .open .answer，防止 class 冲突
• 务必加 tabindex="0" 到触发元素上，并监听 keydown 处理回车/空格，否则键盘不可用

<div data-accordion>
  <button type="button" aria-expanded="false" tabindex="0">点击查看答案</button>
  <div class="answer" aria-hidden="true">答案内容</div>
</div>

事情说清了就结束。关键不是“怎么藏”，而是“谁来决定什么时候露”——浏览器原生机制比手写逻辑更稳，除非你明确知道为什么非要绕开它。