00:00:00
🌍 卷② 浏览器平台能力
20 条。适用场景：判断某个功能还需不需要引第三方库。
「要点」「我的补充」为本人撰写，非原文摘录；特性可用性以链接内官方表述与 caniuse 为准。
一、Baseline：先解决"能不能用"这个问题
21. New to the web platform in May
来源：web.dev · web.dev 读它解决什么：想按月跟进浏览器新增了什么，而不是等到别人博客里偶然看到。
要点
- 月度汇总把四大浏览器引擎的新增能力集中列出，是低成本的跟进方式
- 关注点应放在"进入 Baseline 的能力"，而不是单个浏览器的实验特性
- 这类汇总的价值是发现你不知道自己需要的能力
我的补充：建议的跟进节奏是每月花十分钟扫一遍标题，只深入看与当前项目相关的。别试图全部记住——知道"有这么个东西"就够了，需要时能搜到。订阅 RSS 比定期访问可靠（web.dev 的 feed 在 /static/blog/feed.xml）。
22. April 2026 Baseline monthly digest
来源：web.dev · web.dev 读它解决什么：搞清 Baseline 到底怎么定义"可以用了"。
要点
- Baseline 分两档：Newly available（四大引擎都支持了）与 Widely available（跨引擎支持满 30 个月）
- 这套标准的意义是把"能不能用"从各人经验判断变成可查的客观状态
- 落到项目里，通常应该用 Widely available 的能力，Newly available 需要配降级
我的补充：这是近年前端最实用的一个基础设施——以前判断兼容性得自己在 caniuse 上算用户占比，现在有统一口径。实践建议：面向公众的项目按 Widely available 选型；内网/管理后台可以放宽到 Newly available。MDN 每个特性页顶部现在都有 Baseline 标记，查起来很快。
23. How Baseline Can Help You Ship Less JavaScript
来源：Smashing Magazine · smashingmagazine.com 读它解决什么：项目里那些 polyfill 和工具库，有多少已经可以删了。
要点
- 大量 npm 依赖存在的理由是"当年浏览器不支持"，而这个前提往往已经失效
- 用 Baseline 反查依赖清单，能识别出可以移除的部分
- 少发 JavaScript 的收益是全链路的：下载、解析、执行都省
我的补充：值得专门做一次审计。高频可删的：日期库（Intl.DateTimeFormat 加 Temporal 能覆盖多数格式化需求）、lodash 的大部分函数（原生已有）、classnames（模板字符串够用）、smooth scroll polyfill（scroll-behavior: smooth）、clipboard.js（navigator.clipboard）。方法是把 package.json 的依赖逐个搜一遍它替代的原生 API 现在什么状态，通常能减掉可观的体积。
24. Interop 2026: Continuing to improve the web for developers
来源：web.dev · web.dev 读它解决什么：了解各浏览器厂商今年共同承诺要修齐的能力有哪些。
要点
- Interop 项目让厂商就"今年重点补齐哪些差异"达成一致，并用公开测试通过率跟踪
- 对开发者的意义是可预期：列入 Interop 的能力，一年内跨浏览器一致性会明显改善
- 选题来自开发者调查与实际痛点
我的补充：这份清单可以当做"未来一年可以开始规划使用"的技术雷达。对照着看：如果某能力你现在因为兼容性放弃了，而它在 Interop 列表里，那么明年可能就能用了，值得先把代码结构留好口子。测试通过率在 wpt.fyi 上可以实时看。
二、导航与视图过渡
25. Navigation API - a better way to navigate, is now Baseline Newly Available
来源：web.dev · web.dev 读它解决什么：SPA 路由长期依赖 History API 的各种绕法，导航 API 提供了正规解法。
要点
- History API 的核心缺陷是无法拦截导航、无法知道导航是否成功、无法统一处理前进后退
- Navigation API 提供
navigate事件可以拦截并接管，还能拿到导航类型与目标 - 这让 SPA 路由库的实现大幅简化，也让"离开前确认"这类需求有了正规接口
我的补充：以前拦截路由跳转要么劫持 history.pushState、要么监听 beforeunload（只能拦整页离开，拦不了 SPA 内部跳转），都是绕。有了它，"表单未保存提示"终于能正确实现。Newly available 意味着 Safari 刚跟上，生产用需要判断降级。已有的路由库（vue-router 等）会逐步内部采用，多数人不必直接写。
26. A beginner-friendly guide to view transitions in CSS
来源：MDN Blog · developer.mozilla.org 读它解决什么：想做页面切换的连续动画（元素从 A 页面平滑移动到 B 页面）。
要点
- 视图过渡的核心是浏览器自动为切换前后的状态截图并插值，开发者只需声明哪些元素是"同一个"
- 关键属性是
view-transition-name：前后两个页面上同名的元素会被连起来做动画 - 同文档（SPA）用
document.startViewTransition()，跨文档（MPA）用@view-transition { navigation: auto; }
我的补充：跨文档视图过渡对静态站是重大利好——过去这种"共享元素过渡"效果必须做成 SPA，现在多页静态站加几行 CSS 就有。这个博客理论上可以给文章卡片到详情页加过渡。两个注意点：view-transition-name 必须唯一，重复会报错并放弃动画；动画期间元素是截图（伪元素），不响应交互，所以别做太长。
27. View Transitions: Careful Not To Make Stuff Unclickable
来源：Frontend Masters · frontendmasters.com 读它解决什么：加了视图过渡之后，页面上某些元素点不动了。
要点
- 过渡期间生成的伪元素层覆盖在页面上，可能拦截点击
- 动画时长越长，不可交互的窗口越长，用户会以为页面卡了
- 解决方向是控制时长、必要时用
pointer-events调整
我的补充：这条是上一条的必要补充——炫酷效果的代价常常是可用性。实践准则：视图过渡时长控制在 200–300ms 以内，超过 400ms 用户就能感觉到"要等"。另外务必测键盘导航和快速连续点击：过渡还没结束用户又点了下一个链接，行为是否正确。这类 bug 在演示视频里永远看不出来。
28. Seamless PWA origin migration: Change domains without losing users
来源：Chrome for Developers · developer.chrome.com 读它解决什么：PWA 换域名后，已安装的用户会失联。
要点
- PWA 的身份与 origin 绑定，换域名等于变成另一个应用：已安装的图标、缓存、存储都指向旧域
- 需要专门的迁移机制引导用户过渡，而不是简单重定向
- 涉及 manifest、Service Worker 与存储迁移
我的补充：换域名这件事在任何用了 Service Worker 的站点上都要小心，不限于 PWA。旧域名上的 SW 会长期存活并继续用缓存响应，用户可能几个月看不到新站。换域前必须在旧域部署一个"自毁 SW"：self.registration.unregister() 加清空 caches，否则老用户永远卡在旧版本。这是被反复踩的坑。
三、原生组件与交互
29. Using and Styling the Dialog Element
来源：CSS-Tricks · css-tricks.com 读它解决什么：还在用 div 手写模态框——原生 <dialog> 已经能替代大部分场景。
要点
<dialog>的showModal()自带焦点陷阱、Esc 关闭、::backdrop遮罩、惰性化背景内容，这些手写起来都很容易出错- 样式化靠
::backdrop伪元素，进出场动画需要配合@starting-style与allow-discrete <form method="dialog">提交时自动关闭并回传返回值
我的补充：焦点管理是手写模态框最常做错的部分——打开后焦点要移入、Tab 不能跑到背景、关闭后焦点要还回触发元素。showModal() 全给你处理了，可访问性直接达标。注意 show() 和 showModal() 不同，前者不带遮罩和焦点陷阱。动画需要 @starting-style 才能有进场效果，这点很多人卡住。
30. Exclusive accordions using the HTML details element
来源：MDN Blog · developer.mozilla.org 读它解决什么：手风琴（同时只展开一个）不想为此写 JS。
要点
- 给多个
<details>设置相同的name属性，它们就构成互斥组，展开一个自动收起其他 - 完全无需 JS，且键盘可访问性天然正确
<summary>是可聚焦的触发器
我的补充：这是用 5 个字符（name=）换掉一整个手风琴组件的典型案例。FAQ 页、筛选面板都适用。要加展开动画的话现在可以用 interpolate-size: allow-keywords 配合 height 过渡到 auto——以前 height: auto 无法过渡是个老限制。注意 details 内容在收起时仍在 DOM 里，会被搜索引擎和 Ctrl+F 找到，这通常是好事。
31. Delayed-Then-Instant Tooltips with HTML & CSS Alone
来源：Frontend Masters · frontendmasters.com 读它解决什么：tooltip 需要"第一次悬停延迟出现，之后连续悬停立即出现"这种细腻行为。
要点
- 这个交互模式（延迟后进入"快速模式"）是成熟 UI 库的标配细节，避免鼠标划过时一串 tooltip 乱闪
- 纯 CSS 实现靠
transition-delay的巧妙组合，不需要状态机 - 关键洞察是延迟可以只加在"出现"方向
我的补充：这个细节体现了什么叫打磨——功能上有没有都能用，但有了明显更舒服。这个博客的天气组件 tooltip 就有类似的延迟逻辑（用 JS 定时器实现，卸载时要记得 clearTimeout，否则组件销毁后回调仍会触发）。能用 CSS 表达的交互状态就别用 JS，少一处内存泄漏的机会。
32. The Shifting Line Between CSS States and JavaScript Events
来源：CSS-Tricks · css-tricks.com 读它解决什么：越来越多以前要 JS 的状态现在 CSS 能直接表达，边界在哪。
要点
- CSS 能感知的状态在扩张：
:has()、:user-invalid、容器滚动状态、popover开合 - 判断准则是：状态是否是 DOM 的固有状态——是的话交给 CSS，需要业务逻辑判断的才用 JS
- 用 CSS 表达状态的好处是不受 JS 加载与执行影响
我的补充：这个边界移动的实际收益是删代码。常见可迁移的：表单校验样式（:user-invalid 比手写 .error class 好，它只在用户交互后才生效，不会一进页面就飙红）、弹层开合（popover 属性 + :popover-open）、滚动吸顶样式。留在 JS 里的应该是"需要知道业务含义"的部分，纯视觉状态尽量下沉到 CSS。
33. Exploring the Broadcast Channel API for cross-tab communication
来源：MDN Blog · developer.mozilla.org 读它解决什么：多个标签页之间要同步状态（一个页面登出，其他也登出）。
要点
BroadcastChannel提供同源标签页间的消息广播，API 极简：new BroadcastChannel(name)加postMessage/onmessage- 相比用
localStorage的 storage 事件传消息，语义更清晰且不污染存储 - 不跨 origin，也不持久化——只是实时通道
我的补充：典型用途是登录态同步：一个标签登出，其他标签立刻反应，而不是等用户操作时才发现 401。以前的土办法是监听 storage 事件（改 localStorage 触发其他标签），能用但要写 workaround（同一标签内不触发、要序列化）。注意 BroadcastChannel 传的是结构化克隆，不能传函数和 DOM 节点。
34. Using the Page Visibility API
来源：MDN Blog · developer.mozilla.org 读它解决什么：标签页切到后台时，应该停掉轮询、动画、视频。
要点
document.visibilityState与visibilitychange事件告知页面是否可见- 后台标签的定时器会被浏览器降频甚至暂停，依赖
setInterval的逻辑在后台不可靠 - 正确做法是可见时启动、隐藏时停止，而不是让定时器空跑
我的补充：这个博客的动态壁纸组件就用它——切到后台停止切换、回到前台恢复。踩过的坑值得记一笔：removeEventListener('visibilitychange', () => {}) 传匿名函数摘不掉监听器，必须用具名函数的同一个引用，否则每次进出页面泄漏一个监听器。这类错误不会报错，只会让内存慢慢涨。
四、新兴能力与运行时
35. What's New in WebGPU (Chrome 149-150)
来源：Chrome for Developers · developer.chrome.com 读它解决什么：需要在浏览器里做 GPU 计算或高性能渲染。
要点
- WebGPU 是 WebGL 的后继，暴露现代图形 API 的能力（计算着色器、更好的多线程模型）
- 除了渲染，计算着色器让浏览器内做通用 GPU 计算成为可能，这是端侧 AI 推理的基础
- 版本更新通常涉及着色器语言（WGSL）与设备特性
我的补充：对大多数前端工作暂时无关，但两个方向值得留意：一是端侧模型推理（transformers.js 之类底层用它），二是大数据量可视化（几十万点的图表）。注意 WebGPU 需要 HTTPS 且部分设备/驱动仍不支持，必须检测 navigator.gpu 并准备 Canvas 降级路径。移动端支持度差异较大。
36. Why is WebAssembly a second-class language on the web?
来源：Mozilla Hacks · hacks.mozilla.org 读它解决什么：理解 Wasm 为什么没有像预期那样广泛替代 JS。
要点
- Wasm 长期缺少直接操作 DOM 的能力，所有交互都要经过 JS 胶水层，跨界调用有成本
- 与 JS 的类型互操作（字符串、对象）也需要转换，抵消了部分性能优势
- 这些是设计取舍的结果，社区在推进改善
我的补充：现实的选型判据：Wasm 的甜区是"纯计算、少交互"——图像处理、音视频编解码、加密、物理引擎、把已有 C/C++/Rust 库搬上网页。要做 UI 的话 JS 仍然是更好的选择，用 Wasm 写界面往往得不偿失。判断依据是"跨界调用频率"：每帧调几千次就会被胶水层吃掉收益。
37. Announcing Web Serial Support in Firefox
来源：Mozilla Hacks · hacks.mozilla.org 读它解决什么：浏览器要与串口设备通信（开发板、打印机、仪器）。
要点
- Web Serial 让网页读写串口设备，此前只能靠原生程序或浏览器扩展
- 必须由用户手势触发选择设备，权限模型与 WebUSB、WebBluetooth 一致
- 多引擎支持是这类硬件 API 能否真正被采用的关键
我的补充：这类硬件 API 的共同特点：必须 HTTPS、必须用户手势、必须处理设备随时断开。做工业/教育类 Web 应用（在线烧写固件、读传感器）现在可行度提高了。写代码时记得监听 disconnect 事件——用户拔线是常态而不是异常，不处理就是白屏。
38. Efficient data handling with the Streams API
来源：MDN Blog · developer.mozilla.org 读它解决什么：要处理大文件或流式响应，不想全部读进内存。
要点
- Streams API 让数据可以分块处理：
ReadableStream、WritableStream、TransformStream fetch的response.body就是可读流，可以边下边处理（进度条、流式解析）- 相比
response.json()一次性读完，流式处理的内存占用与文件大小无关
我的补充：两个实用场景。一是大文件上传/下载显示真实进度：读流并累加 chunk 长度，比 XMLHttpRequest 的 progress 事件更灵活。二是流式渲染 LLM 响应——现在最常见的用途，TextDecoderStream 配合 for await...of 就能逐字输出。注意流只能读一次，需要多次用要先 response.clone()。
39. Default styles for h1 elements are changing
来源：MDN Blog · developer.mozilla.org 读它解决什么：<h1> 在 <section> 里的默认字号规则变了，可能影响你的页面。
要点
- 历史行为是嵌套在分区元素里的
h1会自动缩小字号，模拟层级 - 这个行为造成混淆且与实际语义脱节，正在被移除
- 影响面是没有显式设置 h1 字号的页面
我的补充：检查方式很简单：CSS 里搜一下有没有给 h1 显式设 font-size，没有就可能受影响。顺手该做的是给所有标题显式定义字号，不依赖浏览器默认值——这类默认值变更历史上出现过多次。另外这也提醒一件事：h1 应该按文档语义用（通常每页一个），不要为了字号大小选标题级别。
40. Introducing the MDN HTTP Observatory
来源：MDN Blog · developer.mozilla.org 读它解决什么：想快速检查自己站点的 HTTP 安全头配置得如何。
要点
- 扫描并评分常见安全响应头：CSP、HSTS、X-Content-Type-Options、Referrer-Policy、权限策略
- 给出的是可执行的改进项，而不只是打分
- 这类检查应纳入上线检查表
我的补充：静态博客最值得配的三个头：Strict-Transport-Security（强制 HTTPS）、X-Content-Type-Options: nosniff、Referrer-Policy: strict-origin-when-cross-origin。CSP 收益最大但配置最麻烦——内联脚本和第三方统计会让它变复杂，建议先用 Content-Security-Policy-Report-Only 观察一段时间再切正式。Cloudflare Pages 的头要写在构建产物根目录的 _headers 里，放错目录（比如放进 functions/）不生效，这个我踩过。
本卷小结
三条：
- 换域名前先部署自毁 Service Worker。旧域的 SW 会长期用缓存响应，老用户可能几个月看不到新站。
<dialog showModal()>替代手写模态框。焦点陷阱、Esc 关闭、背景惰性化全自带，可访问性直接达标。visibilitychange的监听器必须是具名函数。传匿名箭头函数removeEventListener摘不掉，静默泄漏。