题干与适用场景
请设计一个支持日文假名、繁体中文注音和拼音的内容组件。你会如何组织 ruby 标记，处理多层注音、搜索复制、CSS 不支持时的回退，并评估屏幕阅读器与可访问性风险？
W3C 于 2026 年 6 月 4 日发布 HTML Ruby Markup Extensions Candidate Recommendation Snapshot。该规范修订 HTML 的 ruby 结构，恢复 rb 与 rtc 的合规地位，并定义基文、注音单元、注音容器和多层注音的结构语义。它不是一个自动翻译组件，也没有解决所有屏幕阅读器朗读策略，面试时要区分语义标记、布局样式和辅助技术行为。
面试官考察点
面试官会关注你是否把基文与注音建模为结构化配对，是否能解释交错标记和表格标记的取舍，是否使用 CSS Ruby Layout 控制视觉呈现而非把读音写进图片。还要覆盖语言标注、搜索与复制、无 Ruby 布局时的 rp 回退、SSR/水合一致性、XSS 安全和屏幕阅读器测试边界。
回答前需要澄清的问题
- 内容来源已经给出基文与注音配对，还是组件需要自行切分和生成？
- 一个基文是否有多个语言或层级的注音，例如注音符号和拼音同时存在？
- 浏览器不支持 Ruby 布局时，产品希望内联括号、隐藏注音还是保留原始结构？
- 搜索结果、复制到剪贴板和文本转语音分别需要保留哪些内容？
- 内容是否允许用户提交，是否需要清理 HTML、限制属性和 CSP？
30 秒回答框架
“我先把基文、注音范围和语言作为数据模型，再输出语义化 ruby、rb、rt、rtc、rp 标记。单层注音用交错结构，多字符和多层注音用明确容器或表格结构，避免只依赖浏览器隐式配对。CSS 负责 ruby 位置、字号和回退样式；rp 提供不支持布局时的可见括号。搜索和复制按产品语义保留基文，屏幕阅读器用真实设备和辅助技术测试，不承诺规范没有定义的朗读顺序。所有用户内容先清理再渲染。”
分步骤深入解答
1. 先定义注音数据模型
每个片段包含基文范围、一个或多个注音范围、语言标签和展示策略。日文可用假名，繁体中文可用注音符号或拉丁拼音；同一基文可有多个 rtc 层，但要明确哪个是默认层。数据模型与渲染器分离，避免把字符串切分规则散落在组件里。
2. 选择符合语义的标记
ruby 是整体容器，rb 表示基文单元，rt 表示注音文本，rtc 表示注音容器，rp 提供内联回退内容。简单场景可以让文本直接作为隐式基文单元，但复杂多字符配对应使用明确的 rb，这样 DOM、复制和后续布局更可预测。
3. 处理多字符与多层配对
逐字交错适合简单一对一注音；表格标记先列多个 rb，再列对应的 rt，更能表达复合词和多层注音。多个连续 rt 可由 rtc 组织，语言不同的层级应在 rtc 或 rt 上设置 lang。不要用 CSS 伪元素承载实际读音，因为搜索、复制和辅助技术看不到可靠文本。
<ruby lang="zh-TW">
<rb>美</rb><rtc><rt>ㄇㄟˇ</rt></rtc>
<rtc lang="zh-Latn"><rt>měi</rt></rtc>
</ruby>4. 用 CSS 做布局渐进增强
HTML 提供结构，CSS Ruby Annotation Layout 控制 ruby-position、字号、行高和对齐。默认样式要保证注音不会遮挡基文，也要允许用户放大文字。浏览器不支持 Ruby 布局时，rp 可以显示括号或其他内联提示；不要依赖 display: none 隐藏所有注音而让信息消失。
5. 设计搜索、复制和文本提取
规范专门讨论了搜索与复制交互，但实现仍需在真实浏览器验证。定义复制策略：通常复制基文，必要时追加注音；搜索应能找到基文和注音，而不是因为 DOM 被注音打断而漏词。服务端索引可保存结构化基文和注音字段，客户端不要用正则从已渲染 HTML 猜测配对。
6. 评估辅助技术和国际化
Ruby 常用于帮助儿童、非母语者和识字困难用户，但不同屏幕阅读器可能采用不同朗读启发式。提供语言正确的 lang，保留有意义的文本顺序，并用屏幕阅读器、键盘缩放和高对比度模式测试。不要声称仅靠规范就能解决文本转语音；把已知差异和回退策略记录在可访问性说明中。
7. 做安全、性能和兼容性校验
用户提交的基文和注音必须经过 HTML 清理和属性允许列表，禁止脚本、事件属性和危险 URL。SSR 输出与客户端水合应使用同一配对算法，避免注音闪烁或文本重排。对长文档使用结构化节点和按需渲染，缓存数据模型而不是不安全的 HTML 字符串，并用 WPT 和目标浏览器矩阵验证。
高质量示范回答
我会先定义基文范围、注音层、语言和展示策略，再由渲染器输出语义化 ruby 标记。简单一对一注音使用交错结构，多字符或多层注音使用明确的 rb 与 rtc，不同语言在对应层标注 lang。CSS Ruby Layout 只负责位置、字号和行高，rp 为不支持 Ruby 布局的浏览器提供内联回退。复制策略默认保留基文，搜索同时索引基文和注音，具体行为在真实浏览器中测试。由于辅助技术朗读没有被这份规范完全统一，我会测试屏幕阅读器、键盘、缩放和高对比度，并记录差异与回退。所有输入先清理，SSR 与客户端共用同一数据模型和配对算法，最后用 WPT 和浏览器矩阵验证结构、布局、搜索、复制和安全边界。
常见错误
- 只用 CSS 伪元素显示读音 → 搜索和辅助技术缺少文本 → 用语义化 Ruby 标记表达内容。
- 把每个字符硬编码成交错节点 → 复合词和多层注音难以维护 → 用结构化配对和
rtc容器。 - 把
rp当成必需视觉括号 → 支持布局的浏览器出现重复内容 → 只在回退场景显示。 - 忽略
lang→ 朗读和字体选择错误 → 在基文和注音层标注准确语言。 - 承诺所有屏幕阅读器顺序一致 → 规范没有定义完整 TTS 行为 → 做设备测试并记录差异。
- 直接渲染用户 HTML → 产生脚本注入 → 清理元素、属性和 URL。
追问及应对
什么时候用 rb，什么时候依赖隐式基文？
简单单层注音可依赖隐式基文，但复合词、表格标记和需要稳定 DOM 的应用应明确使用 rb，让配对、复制和调试更清楚。
同一基文有假名和罗马字怎么办？
用多个 rtc 层或明确的注音容器，并在每层标注 lang；产品要提供默认层和切换策略，不让 CSS 选择承担语义决定。
不支持 Ruby 布局时如何回退？
保留文本结构，用 rp 显示括号或内联分隔，确保基文和注音仍可读；不要隐藏实际内容或生成一张不可选择的图片。
如何定义复制行为？
先按产品目标决定复制基文、基文加注音或两者结构化导出，再在 Chromium、Firefox、Safari 和移动端验证；不要假设 DOM 顺序就是用户期望的字符串。
如何证明注音没有破坏可访问性？
检查语言标签、焦点顺序、缩放、键盘操作和屏幕阅读器输出，覆盖无注音、单层、多层和回退模式，并把已知辅助技术差异公开记录。