❌

阅读视图

发现新文章，点击刷新页面。

顶层元素问题：popover vs. dialog

✇掘金 前端
掘金安东尼

原文：Top layer troubles: popover vs. dialog 作者：Stephanie Eckles 日期：2025年12月1日 翻译：田八

来源：前端周刊

你是否曾尝试通过设置 z-index: 9999 解决元素层级问题？如果是，那你其实是在与一个基础的CSS概念 ——层叠上下文—— 斗争。

层叠上下文定义了元素在第三维度（即“z轴”）上的排列顺序。你可以把z轴想象成视口中层叠上下文根节点与用户（即通过浏览器视口观察的你）之间的DOM元素的层级。

image.png

一个元素只能在同一层叠上下文中重新调整层级。虽然 z-index 是实现这一点的工具，但失败往往源于层叠上下文的变化。这种变化可能通过多种方式发生，例如使用固定定位（fixed）、粘性定位（sticky）元素，或是将绝对定位（absolute）/相对定位（relative）与 z-index 结合使用等，MDN 上列出了更多原因。

现代网页设计有一个“顶层”特性，它保证使其位于所有其他层叠上下文的最顶层。它覆盖整个视口，不过顶层中的元素实际可见尺寸可能更小。

将元素提升到顶层，可使其摆脱原本所在的任何层叠上下文。

虽然顶层直接解决了一个与CSS相关的问题，但目前还没有属性可用于将元素提升到顶层。取而代之的是，某些元素和特定条件可以访问顶层，例如通过 <div> 标签显示的原生对话框 showModal() 和被指定为 Popover 的元素。

Popover API是一项新推出的 HTML 功能，它允许你声明式的创建非模态覆盖元素。通过使用 Popover API 用来摆脱任何层叠上下文，这是它的一个理想特性。然而，在急于选择这种原生能力之前，需要注意一个潜在的问题。

场景设定

想象一下，在2025年的网络世界：你的网页应用包含一个通过“Toast”消息显示通知的服务。你知道的，就是那些通常出现在角落或其他不太可能遮挡其他用户界面（UI）位置的弹出消息。

通常，这些Toast通知通常用于实时提醒，比如保存成功，或者表单提交失败等错误提示。它们有时有时间限制，或者包含如关闭按钮这样的关闭机制。有时它们还包含额外操作，例如“重试”选项，用于重新提交失败的工作流。

既然您的应用紧跟时代潮流，你最近决定将Toast升级为使用Popover API。这样你就可以将Toast组件放置在应用的任何结构中，而无需为了解决层叠上下文问题而采用一些变通方法。毕竟，Toast必须显示在所有其他元素之上，因此通过 Popover 实现顶层访问是明智之举！

你发布了改进版本，并为自己的工作感到自豪。

发布的当周晚些时候，你收到了一份紧急错误报告。不是普通的错误报告，而是一个可访问性违规报告。

Dialog vs. popover

你的应用很新潮，你之前也升级使用了原生HTML对话框。那是一次很棒的升级，因为你用原生 Web 功能取代了对 JavaScript 的依赖。这也是你兴奋地将Toast也升级为使用Popover的另一个原因。

那么，错误是什么呢？一位键盘用户正在使用一个包含对话框的工作流程，对话框打开期间，后台进程触发了一个弹出式通知。该通知提示存在错误，需要用户进行交互。

当这位键盘用户试图将焦点切换到Toast上时，出现了错误。他们虽然在视觉上能看到Toast显示在对话框背景之上，但焦点无法成功进入Toast，而是意外地跳到了浏览器UI上。

你可以在这个CodePen示例中亲自体验这个错误，使用Tab键，你会发现你永远无法访问到Toast。你也可以尝试使用屏幕阅读器，会发现虚拟光标也无法进入Toast。

CodePen

如果你能够点击弹出框，可能会觉得至少点击操作是可行的。但很快我们就会发现，事情并非如此。

为什么Toast弹出框无法访问

虽然顶层可以超越标准的层叠上下文，但顶层中的元素仍然受分层顺序的影响。最近添加到顶层的元素会显示在之前添加的顶层元素之上。这就是为什么Toast在视觉上会显示在对话框背景之上。

如果弹出框在视觉上可用，那为什么通过键盘或屏幕阅读器的虚拟光标却无法访问呢？

原因在于弹出框与 模态 对话框之间存在竞争关系。当通过 showModal()方法启动原生HTML对话框时，对话框外部的页面会变为 惰性状态。惰性状态 是一种必要的可访问性行为，它会隔离对话框内容，并阻止通过Tab键和虚拟光标访问背景页面。

这个错误是由于Toast弹出框是背景页面DOM的一部分。这意味着由于它位于对话框DOM边界之外，所以也变成了惰性状态。

但是，由于顶层顺序的原因，因为它是在对话框打开后创建的，所以在视觉上，它被放置在对话框的顶部，这一点可能会让你感到困惑。

如果你以为点击弹出框就能关闭它，实际上并非如此，尽管弹出框确实会消失。真正发生的情况是，你触发了弹出框的 轻触关闭 行为。这意味着它关闭是因为你实际上点击了它的边界之外，因为对话框捕获了点击操作。

所以，虽然弹出框被关闭了，但“重试”按钮实际上并没有被点击，这意味着任何关联的事件监听器都不会被触发。

即使你创建了一个自动化测试来专门检查当对话框打开时Toast的提醒功能，该自动化测试仍可能出现误报，因为它触发了对Toast按钮的编程式点击。这种伪点击错误地绕过了由于对话框导致页面变为惰性状态所引发的问题。

重新获得弹出框访问权限

解决方案有两个方面：

  1. 将弹出框(popover)在DOM中实际放置在对话框(dialog)内部。
  2. 确保使用 popover="manual"，以防止对话框内的点击操作过早触发弹出框的轻触关闭。

完成这两步后，弹出框现在既在视觉上可用，又可以通过任何方式完全交互。

Codepan

经验教训与额外考虑

我们了解到，如果你的网站或应用有可能同时显示弹出框和对话框，并且它们有独立的时间线，那么你需要想出一种在对话框内启动弹出框的机制。

或者，您可以选择在对话框关闭之前禁用后台页面弹出窗口。但如果通知需要及时交互，或者对话框内容有可能触发 Toast 提示，则此方法可能并不理想。

除了可见性和交互性之外，您可能还需要考虑另一个问题：弹出窗口是否需要在对话框关闭后继续保持打开状态。也就是说，即使对话框关闭，弹出窗口也需要保持打开状态，例如继续等待用户执行操作。

虽然我非常支持使用原生平台功能，而且我认为弹出框（popover）尤其出色，但有时冲突是无法完全避免的。事实上，您可能已经遇到过类似的问题，即模态对话框的惰性行为。因此，本文的主要目的是提醒您，如果同时显示背景弹出框和模态对话框，可能会出现问题，因此不要完全放弃之前自定义的弹出框架构。

如果这个问题目前或将来会影响到你的工作，请关注这个HTML问题，其中正在讨论解决方案。

关于斯蒂芬妮·埃克尔斯

Stephanie Eckles 是 Adobe Spectrum CSS 的高级设计工程师，也是 CSSWG 的成员，同时还是 ModernCSS.dev 的作者。Steph 拥有超过 15 年的 Web 开发经验，她乐于以作家、研讨会讲师和会议演讲者的身份分享这些经验。她致力于倡导无障碍设计、可扩展 CSS 和 Web 标准。业余时间，她是两个女儿的妈妈，喜欢烘焙和水彩画。

博客：ModernCSS.dev Mastodon：@5t3ph

译者注：

  1. popover：弹出框指的是轻提示的弹出式框，没有过多的交互逻辑
  2. dialog：对话框指的是带有交互逻辑的弹出框，例如存在确认和取消按钮，输入框等

这两个都是新特性，具体内容可参考MDN

TypeScript 严格性是非单调的：strict-null-checks 和 no-implicit-any 的相互影响

✇掘金 前端
掘金安东尼

原文： TypeScript strictness is non-monotonic: strict-null-checks and no-implicit-any interact

翻译： 嘿嘿

来源：前端周刊

TypeScript 编译器选项 strictNullChecks 和 noImplicitAny 以一种奇怪的方式相互作用：仅启用 strictNullChecks 会导致类型错误，而在同时启用 noImplicitAny 后这些错误却消失了。这意味着更严格的设置反而导致更少的错误！

这虽然是一个影响不大的奇闻异事，但我在实际工作中确实遇到了它，当时我正在将一些模块更新为更严格的设置。

背景

TypeScript 是驯服 JavaScript 代码库的强大工具，但要获得最大的保障，需要在“严格”模式下使用它。

在现有的 JavaScript 代码库中采用 TypeScript 可以逐步完成：逐个打开每个严格的子设置，并逐一处理出现的错误。这种渐进式方法使得采用变得可行：不要在一次大爆炸中修复整个世界，而是进行多次较小的更改，直到最终世界被修复。

在工作中，我们最近一直在以这种方式逐步提高代码的严格性，然后我遇到了这种相互作用。

示例

下面这段代码中，array 的类型是什么？

const array = [];
array.push(123);

作为一个独立的代码片段，它看起来奇怪且毫无意义（“为什么不直接用 const array = [123];？”），但它是真实代码的最小化版本。

const featureFlags = [];

if (enableRocket()) {
  featureFlags.push("rocket");
}
if (enableParachute()) {
  featureFlags.push("parachute");
}

prepareForLandSpeedRecord(featureFlags);

这里没有显式的类型注解，所以 TypeScript 需要推断它。这种推断有点巧妙，因为它需要“时间旅行”（指需要运行后续语句后回头去修改推断的类型，类似正则回溯）：const array = [] 这个声明并没有说明数组中可能包含什么，这个信息只来自代码后面出现的 push。

考虑到所有这些，推断出的确切类型依赖于两个 TypeScript 语言选项也就不足为奇了：

strictNullChecks noImplicitAny 推断类型
最不严格 ❌ ❌ any[]
❌ ✅ number[]
✅ ❌ never[]
最严格 ✅ ✅ number[]

选项说明

这里影响推断类型的两个选项是：

  • strictNullChecks：正确强制处理可选/可为空的值。例如，启用后，一个可为空的字符串变量（类型为 string | null）不能直接用在期望普通 string 值的地方。
  • noImplicitAny：避免在一些模棱两可的情况下推断出“全能”的 any 类型。

最好同时启用它们：strictNullChecks 解决了“十亿美元的错误”，而 noImplicitAny 减少了感染代码库的容易出错的 any 的数量。

问题所在

我们上表中第三种配置，即启用 strictNullChecks 但禁用 noImplicitAny 时，推断出 array: never[]。因此，代码片段无效并被报错（在线示例）：

array.push(123);
//         ^^^ 错误：类型“123”的参数不能赋给类型“never”的参数。

没有任何东西（既不是字面量 123，也不是任何其他 number，也不是任何其他东西）是 never 的“子类型”，所以，是的，这段代码无效是合理的。

奇怪之处

“启用一些更严格的要求，然后得到一个错误”并不令人惊讶，也不值得注意……但让我们再仔细看看表格：

strictNullChecks noImplicitAny 推断类型
最不严格 ❌ ❌ any[]
❌ ✅ number[]
报错！ ✅ ❌ never[]
最严格 ✅ ✅ number[]

所以，如果我们从一个宽松的代码库开始，并希望使其变得严格，我们可能会：

  1. 启用 strictNullChecks，然后遇到一个新错误（不奇怪），然后
  2. 解决这个错误，无需更改代码，只需启用 noImplicitAny（奇怪！）。

当我们朝着完全严格的方向前进时，逐个启用严格选项可能会导致一些“虚假的”错误短暂出现，仅仅出现在中间的半严格状态。随着我们打开设置，错误数量会先上升后下降！

我个人期望启用严格选项是单调的：启用的选项越多 = 报错越多。但这一对选项违反了这种期望。

解决方案

在尝试使 TypeScript 代码库变得严格时，有几种方法可以“解决”这种奇怪现象：

  1. 直接用显式注解修复错误，例如 const array: number[] = []。
  2. 使用不同的逐个启用顺序：先启用 noImplicitAny，然后再启用 strictNullChecks。如上表所示，按照这个顺序，两个步骤的推断结果都是 array: number[]，因此没有错误。
  3. 同时启用它们：不要试图完全渐进，而是将这两个选项作为一步启用。

解释

为什么启用 strictNullChecks 并禁用 noImplicitAny 会导致一个在其他地方不出现的错误？jcalz 在 StackOverflow 上解释得很好，其核心是：

  • 这种有问题的组合是一个为了向后兼容而留下的边缘情况，其中 array 的类型在其声明处被推断为 never[]，并在后续代码中被锁定。
  • 启用 noImplicitAny 会使编译器在模棱两可的位置（在没有 noImplicitAny 时会推断为 any 的地方）使用“演化”类型（evolving types，可理解为先推断为 any/never 然后后续追加推断的类型）：因此，array 的类型不会在其声明行被确定，并且可以结合来自 push 的信息进行推断。

评论

这感觉像是一个有趣的脑筋急转弯，而不是一个重大问题：

  • 修复这些虚假错误并不是一个重大的负担或显著的浪费时间，而且可以说，添加注解可能使这类代码更清晰。
  • 半严格状态可能有奇怪的行为是可以理解的：我想 TypeScript 开发者更关心完全严格模式下的良好体验，希望中间状态只是垫脚石，而不是长期状态。

总结

TypeScript 选项 strictNullChecks 和 noImplicitAny 以一种奇怪的方式相互作用：以“错误”的顺序逐个启用它们会导致错误出现然后又消失，违反了单调性的期望（启用的严格选项越多 = 错误越多）。这可能发生在真实代码中，但影响极小，因为很容易解决和/或规避。

⏰前端周刊第445期（2025年12月15日–12月21日）

✇掘金 前端
掘金安东尼

📢 宣言：每周更新国外论坛的前端热门文章，推荐大家阅读/翻译，紧跟时事，掌握前端技术动态，也为写作或突破新领域提供灵感~

欢迎大家访问：github.com/TUARAN/fron… 顺手点个 ⭐ star 支持，是我们持续输出的续航电池🔋✨！

在线网址：fwdc.pages.dev/

前端周刊封面

💬 推荐语

本期内容涵盖 HTML 现状、React2Shell 安全事件复盘与防护、可访问性与性能指标实践、现代 CSS 新能力，以及框架与工具链的最新趋势。

🗂 本期精选目录

🧭 Web 开发

🛠 工具

⚡ 性能

🧪 Demo

🎨 CSS

💡 JavaScript

⚛️ React

🧾 前端周刊 · 上周内容「价值判断大表」

分类 标题 核心主题 影响面 趋势性 可行动性 综合优先级 编辑部判断
Web State of HTML 2025 HTML 原生能力演进 ⭐⭐⭐⭐☆ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐☆ S 前端回归平台能力，必读
Web React2Shell 百万美元挑战 前端安全 / RSC ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐☆ S+ 架构级安全信号
Web React2Shell 事件复盘 前端攻击面 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐☆ S+ 企业前端必看
Web <time> 元素语义讨论 HTML 语义 ⭐⭐☆☆☆ ⭐⭐⭐☆☆ ⭐⭐☆☆☆ B 思想有趣，实用性一般
Web Dynamic Datalist API + 原生组件 ⭐⭐☆☆☆ ⭐⭐⭐☆☆ ⭐⭐⭐☆☆ B 可写 Demo
Web 衡量功能真实影响 产品 × 工程 ⭐⭐⭐⭐☆ ⭐⭐⭐☆☆ ⭐⭐⭐⭐☆ A 很适合写方法论
A11y WCAG 3.3.9 指南 可访问性 ⭐⭐⭐☆☆ ⭐⭐⭐⭐☆ ⭐⭐⭐☆☆ A- 企业项目价值高
工具 JS Bundler Grand Prix 构建工具对比 ⭐⭐⭐⭐☆ ⭐⭐⭐⭐☆ ⭐⭐⭐⭐☆ A 选型 & 分享利器
工具 Vitest 4 迁移指南 测试体系 ⭐⭐⭐☆☆ ⭐⭐⭐⭐☆ ⭐⭐⭐⭐☆ A 团队升级必备
性能 LCP 深度拆解 Core Web Vitals ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐☆ ⭐⭐⭐⭐☆ S 性能工程核心
性能 无限滚动 CLS 优化 页面稳定性 ⭐⭐⭐⭐☆ ⭐⭐⭐⭐☆ ⭐⭐⭐⭐☆ S- 实战价值极高
性能 屏幕尺寸懒加载 图片性能 ⭐⭐⭐☆☆ ⭐⭐⭐☆☆ ⭐⭐⭐☆☆ B 技巧型
Demo GSAP 曲线路径动画 动效 ⭐⭐☆☆☆ ⭐⭐⭐☆☆ ⭐⭐⭐☆☆ C+ 灵感向
Demo 页面过渡策略 UX ⭐⭐⭐☆☆ ⭐⭐⭐☆☆ ⭐⭐⭐☆☆ B 可做设计分享
Demo Toon Text CSS 创意 ⭐⭐☆☆☆ ⭐⭐⭐☆☆ ⭐⭐☆☆☆ C 收藏即可
CSS scroll-state(scrolled) 新 CSS API ⭐⭐⭐⭐☆ ⭐⭐⭐⭐☆ ⭐⭐⭐☆☆ A 值得跟踪
CSS Anchor Positioning 布局能力 ⭐⭐⭐⭐☆ ⭐⭐⭐⭐☆ ⭐⭐⭐☆☆ A 未来组件基础
CSS Masonry → grid-lanes 布局演进 ⭐⭐⭐⭐☆ ⭐⭐⭐⭐⭐ ⭐⭐⭐☆☆ A+ CSS 重大进展
CSS Dialog View Transitions 原生过渡 ⭐⭐⭐☆☆ ⭐⭐⭐⭐☆ ⭐⭐⭐☆☆ A- 框架替代信号
CSS VoxCSS CSS 引擎 ⭐⭐☆☆☆ ⭐⭐⭐☆☆ ⭐⭐☆☆☆ C 实验性
JS JS 内存效率 性能工程 ⭐⭐⭐⭐☆ ⭐⭐⭐☆☆ ⭐⭐⭐⭐☆ A 工程向干货
JS WebAssembly 使用时机 WASM ⭐⭐⭐☆☆ ⭐⭐⭐☆☆ ⭐⭐⭐☆☆ B 知道即可
JS 多品牌 Token 系统（Vue） 设计系统 ⭐⭐⭐⭐☆ ⭐⭐⭐⭐☆ ⭐⭐⭐⭐☆ A 企业前端价值高
JS 三大框架性能对比（2026） 框架选型 ⭐⭐⭐☆☆ ⭐⭐⭐☆☆ ⭐⭐☆☆☆ B- 参考，不迷信
React RSC Explorer RSC 可视化 ⭐⭐⭐⭐☆ ⭐⭐⭐⭐⭐ ⭐⭐⭐☆☆ A+ 理解 RSC 必备
React Next.js 国际化 工程实践 ⭐⭐⭐☆☆ ⭐⭐⭐☆☆ ⭐⭐⭐⭐☆ A- 实用指南
React Vite vs Webpack 构建体系 ⭐⭐⭐⭐☆ ⭐⭐⭐⭐☆ ⭐⭐⭐⭐☆ A 架构选型好文

⏰前端周刊第444期（2025年12月8日–12月14日）

✇掘金 前端
掘金安东尼

📢 宣言

每周更新国外论坛的前端热门文章，推荐大家阅读/翻译，紧跟时事，掌握前端技术动态，也为写作或突破新领域提供灵感~

欢迎大家访问：github.com/TUARAN/fron… 顺手点个 ⭐ star 支持，是我们持续输出的续航电池🔋✨！

在线网址：fwdc.pages.dev/

bannerv2.png

💬 推荐语

本期周刊聚焦前端技术的性能与创新：从 React Server Components 的安全性提升到 CSS 滚动触发动画的原生实现，从 TypeScript 7 原生编译器的影响到 Deno 工具链的持续演进。CSS Wrapped 2025 回顾了 CSS 的重大进展，性能优化深入到复杂 Web 应用的底层机制，前端开发正向着更安全、更高效、更原生的方向迈进。

🗂 本期精选目录

🧭 Web 开发

⚡ 性能

🛠 工具

🎨 CSS

💡 JavaScript

TypeScript

React

Angular

📌 小结

从 React Server Components 的安全性修复，到 CSS 原生滚动动画的突破；从 TypeScript 7 原生编译器的影响分析，到 ES2026 对 JavaScript 痛点的解决，这一周的前端技术展现出"性能优化 + 安全加固 + 原生能力增强"的多维度发展。CSS Wrapped 2025 总结了 CSS 在状态管理和逻辑处理方面的巨大进步，前端开发正在获得更强大的原生能力，同时也需要更加关注安全性和性能优化。

✅ OK，以上就是本次分享，欢迎加我们威 atar24，备注「前端周刊」，我们会邀请你进交流群👇

🚀 每周分享技术干货 🎁 不定期抽奖福利 💬 有问必答，群友互助

❌