AI 摘要：Chrome 143 正式发布，本次更新带来了对锚点定位元素（anchor positioned elements）的新式容器查询（anchored fallback container queries），改进了背景图像定位语法（side-relative background-position），并新增对 font-language-override 的支持，使开发者可精确控制字体替代语言标签。在提高 CSS 表现力的同时，也强化了排版的一致性与多语言支持。

1. CSS 新特性
• Anchored fallback container queries：新增 @container anchored(fallback)，可基于元素定位的备用状态（position-try-fallbacks）设置不同样式，用于调整锚点元素的连线或动画表现。
• Side-relative background positioning：现在可在 background-position-x/y 长属性中直接使用相对边位置语法（如 left 30px、bottom 20px），提高图像定位灵活性，该特性现已进入 Baseline 新可用级别。
• Font language override：新增 font-language-override 属性，允许为 OpenType 字形替换指定自定义四字语言代码，从而覆盖系统语言设置，便于实现多语言、特殊字体排版控制。

2. 版本信息与资源链接
• 详细更新内容见 Chrome 143 release notes。
• 开发者工具更新详情：What's new in Chrome DevTools (143)。
• 功能状态更新在 ChromeStatus.com。
• Chrome release calendar 提供未来版本发布时间表。

3. 社区与后续更新
• 推荐订阅 Chrome Developers YouTube channel 获取最新视频提示。
• 关注 Chrome 团队在 X 或 LinkedIn 的最新发布。
• 官方将于 Chrome 144 发布时继续更新新功能说明。

Chrome for Developers

New in Chrome 143  |  Blog  |  Chrome for Developers

CSS anchored fallback container queries, side-relative positioning for background position longhands, and more.

AI 摘要：文章宣布 WebGPU 正式在 Chrome、Edge、Firefox 与 Safari 上全面支持，这标志着网页端高性能计算和 3D 图形的新时代。WebGPU 不仅替代 WebGL，更在性能与设计层面跃升，支持现代 GPU 功能、Compute Pipeline（通用计算管线）和 Render Bundles（渲染指令集复用）等特性，为游戏、AI 推理、视频处理和物理仿真提供桌面级性能。文章还介绍了各浏览器与操作系统的支持情况以及生态圈的成熟度，包括 Babylon.js、Three.js、ONNX Runtime、Transformers.js 等框架的支持，并感谢各大公司与开发者的多年协作。

1. WebGPU 的意义与特性
• WebGPU 是 WebGL 的继任者，提供更现代、更高效的 GPU 接口。
• 设计包含符合 JavaScript 习惯的 API 与现代着色语言（Shader Language）。
• 支持 Compute Pipeline，让网页端可以执行机器学习推理、模型训练、视频处理等高性能任务。
• Render Bundles 能记录并重用渲染命令，提高性能、降低 CPU 开销。
• 示例：Babylon.js 的 Snapshot Rendering 通过 Render Bundles 提升渲染性能约 10 倍。

2. 浏览器与系统支持现状
• Chrome / Edge：在 Windows（Direct3D 12）、macOS、ChromeOS 自 v113 起支持；Android 自 v121 起支持。
• Firefox：Windows 自 v141 起支持，macOS ARM64 自 v145 起支持。
• Safari：在 macOS、iOS、iPadOS、visionOS 的版本 26 中支持。
• Linux、Android 及部分平台的支持仍在持续开发中，可查看 Implementation Status。

3. WebGPU 生态系统的成长
• 主流框架已支持 WebGPU，包括 Babylon.js、Three.js、PlayCanvas、ONNX Runtime、Transformers.js、React Native WebGPU、TypeGPU、Unity WebGPU。
• 底层引擎如 Dawn (Chromium) 与 wgpu (Firefox) 可独立使用，方便跨平台开发。
• 借助 WebAssembly (Wasm)、Emscripten、Rust web-sys 等工具，可将原生 GPU 应用移植至 Web。

4. 致谢与社区协作
• WebGPU 的成功来自 W3C GPU for the Web Working Group 的多年协作。
• 感谢多家公司与贡献者，包括 Apple、Google、Intel、Microsoft、Mozilla 等。
• 特别致谢开发者 Corentin Wallez、Ken Russell、Thomas Lucchini 等。

web.dev

WebGPU is now supported in major browsers  |  Blog  |  web.dev

Read about the biggest web graphics launch since WebGL. WebGPU is supported across major browsers, bringing unparalleled performance to the web.

AI 摘要：文章介绍了 Chrome 144 对 CSS 属性 overscroll-behavior 的改进：该属性现在在“不可滚动的滚动容器”上也有效，这意味着开发者可以用简单的 CSS 代码阻止页面在对话框（<dialog>）打开时滚动。作者解释了这一特性的技术背景、过去的限制及其在不同浏览器支持上的现状，并展示了一个实现示例。

Bram.us

Use overscroll-behavior: contain to prevent a page from scrolling while a <dialog> is open

Chrome 144 features a small change to overscroll-behavior: it now also works on non-scrollable scroll containers. While this change might seem trivial, it fixes an issue developers have been dealing with for ages: prevent a page from scrolling while a (modal)…

在 Chrome 144.0.7512.0（当前 Canary 版本）中，我们扩展了 width / height 检查，以检查 width 或 height 是否真的发生了变化。
如果 width / height 不变，则无需计算布局，因此也无需强制动画在主线程上运行。

AI 摘要：文章介绍了 Chrome Canary（144.0.7512.0 版本）在动画性能上的新改进：当 width 或 height 在关键帧中并未实际变化时，动画不再被强制在主线程运行，而是可在合成线程（Compositor）上执行，从而显著提升性能。该优化改变了 Blink 对动画可合成判断的逻辑，对视图过渡（View Transitions）等场景尤其有利。作者也讨论了后续可控方案、兼容性影响与手动优化替代方法。

1. 性能与动画基础
• 解释为何过往 width / height 动画会触发 Layout，必须在主线程执行
• 说明渲染管线（rendering pipeline）中 Layout 的代价
• 传统认为应避免对这些属性做动画

2. Chrome 新改进（从版本 144.0.7512.0 开始）
• Blink 引擎增加了判断逻辑：若关键帧中 width / height 值不变，则动画可在合成线程上运行
• 展示了新旧判断流程图差异及其性能收益
• 对视图过渡动画（::view-transition-group(*)）的直接正面影响

3. 实现细节与特殊情境
• 介绍设计判断逻辑时考虑的复杂情境，如隐式关键帧、auto 值等
• 提及其他浏览器（Firefox、Safari）尚未有类似优化
• Blink 团队确保多种 CSS 表达形式都在判断范围内

4. 后续展望与开发者优化建议
• 链接至 W3C 讨论提案 w3c/csswg-drafts#13064，计划为开发者提供更多控制
• 提出当前自我优化方案：用 scale 动画取代宽高变化
• 引用了 Google Search 实际应用与 Motion 框架在变形修正上的做法

5. 影响与意义
• 此更改让许多原本“卡顿”的过渡动画直接获得加速
• 鼓励社区和其他浏览器跟进，共同提升 Web 动画性能

AI 摘要：本文系统梳理网页动画性能的分级标准，从浏览器渲染管线（render pipeline）的底层原理出发，解释为何某些动画（如 transform、opacity 等）能高效运行于 GPU 的 compositor 线程，而另一些（如涉及布局、重绘的动画）则极为耗费资源。作者将动画按性能分为 S 到 F 六个等级，指出各层级的触发条件、适用场景及典型陷阱，并给出实践经验（如 will-change 的使用、CSS 变量的潜在灾难、“thrashing”问题等），帮助开发者建立动画性能直觉与优化策略。

1. 渲染管线与性能基础
• 解释浏览器渲染的三个阶段：Layout、Paint、Composite，并指出触发一个阶段会引发其后所有阶段。
• 区分主线程（main thread）与合成线程（compositor thread）的运行逻辑，说明主线程阻塞将导致动画卡顿。

2. 分级体系（Tiers）总览
• S-Tier：完全运行于 compositor 线程的硬件加速动画，性能最佳。
• A-Tier：在主线程驱动但仅触发 compositor 操作的动画。
• B-Tier：含有一次性 DOM 测量成本的动画。
• C-Tier：触发 Paint 的动画。
• D-Tier：触发布局（Layout）重新计算。
• F-Tier：存在频繁读写 DOM 的“thrashing”灾难级动画。

3. S-Tier：硬件加速动画策略
• 可在 compositor 线程执行的属性有 transform、opacity、filter、clip-path。
• 借助 CSS、Web Animations API（WAAPI）或 Motion 等库实现流畅动画。
• 滚动动画的性能优势源于滚动本身在 compositor 线程执行。
• “去优化”风险：Safari 等浏览器可能丢失硬件加速。
• GPU 图层（layer）太大易耗尽内存，滤镜（尤其是 blur）成本高昂。

4. A-Tier：主线程驱动的合成动画
• 动画触发合成层更新而非重绘，前提是元素已成为图层（如 will-change）。
• JS 动画库（如 GSAP）或 requestAnimationFrame 实现的动画多属此类。
• 利用 IntersectionObserver 可节省主线程资源并暂停不可见动画。
• 提及 Shader 动画性能超强但仍受主线程同步影响。

5. B-Tier：带有预处理的高效布局动画
• Motion 的 layout 动画使用 FLIP（First, Last, Invert, Play）技术，通过 transform 模拟尺寸变化，减少重排。
• 初始测量存在成本，但整体能显著优化动画流畅度。

6. C-Tier：触发重绘的动画与陷阱
• 改变颜色、圆角等属性触发 Paint，相比几何变化轻一些。
• 警惕 CSS 变量（CSS Variables）导致不可预测性能开销：尤其全局继承时全树样式重算。
• 优化策略：缩小变量作用域或用 @property 禁止继承。
• SVG 属性动画与 View Transition API 动画的性能权衡与实践改进。

7. D-Tier：布局驱动的高成本动画
• 改变 width、margin、grid-template-columns 等属性会引发重布局。
• 使用 position: absolute/fixed 或 contain CSS 属性可减少布局范围。

8. F-Tier：性能“地狱”——样式与布局 Thrashing
• 反复读写 DOM 尺寸（如 offsetWidth）导致强制同步布局。
• 建议通过批量化读写（如 Motion 的 frame API）避免 thrashing 问题。

9. 结论
• 动画性能优化不止是“黑魔法”，而是一门平衡内存、渲染步骤与硬件加速的艺术。
• 理解渲染管线可让开发者具备判断性能瓶颈的直觉，S 级动画不代表无代价，关键是为实际体验做正确取舍。

motion.dev

The Web Animation Performance Tier List - Motion Blog

Learn what makes web animations fast, slow, and everything in between with our 2025 web animation performance tier list.

AI 摘要：Chrome 142 引入了多项前端开发相关的新特性，包括用于滚动标记的 :target-before 与 :target-after 伪类、支持比较运算符的 CSS 样式容器查询 (style container queries) 与 if() 函数的范围语法 (range syntax)，以及可用于交互触发的 interestfor 属性。

1. 样式与选择器增强
• 新增 :target-before 和 :target-after 伪类，用于精确匹配滚动标记上下文中的前后状态，实现滚动位置的更直观样式反馈。
• 该伪类配合 :target-current 共同用于管理同组滚动标记的状态，可根据文档平面树 (flat tree order) 定义前后关系。

2. CSS 条件查询能力升级
• 样式容器查询与 if() 函数新增范围语法 (range syntax)，支持通过比较运算符（如 >、<）判断数值型样式变量。
• 可在样式级别进行动态比较，包括自定义属性、文字值 (literal) 与替代函数值 (attr()、env() 等)，前提是比较双方需为同一数据类型，如 <length>、<number>、<percentage> 等。
• 提供灵活的 CSS 逻辑表达方式，例如根据容器宽度或自定义属性值动态切换样式。

3. 新的用户交互机制：Interest Invokers
• 新增 interestfor 属性，可在 <button> 与 <a> 元素上声明“兴趣触发”行为。
• 用户通过长按、悬停或特殊快捷键表现出“兴趣”时，浏览器将触发目标元素的 InterestEvent，默认动作可显示或隐藏弹出层 (popover)。
• 为交互式组件提供无需脚本的原生事件机制，提高用户体验与无障碍交互能力。

4. 延伸阅读与订阅
• 文章并列出扩展资源，包括 Chrome 142 Release Notes、DevTools 更新、ChromeStatus、Release calendar 等。
• 鼓励开发者通过 YouTube、X、LinkedIn 等渠道订阅 Chrome Developers 更新，以持续获取版本迭代信息。

Chrome for Developers

New in Chrome 142  |  Blog  |  Chrome for Developers

The :target-before and :target-after pseudo-classes, range syntax for container queries, and more.

AI 摘要：介绍了已进入 Baseline 的新浏览器功能 URLPattern API，它为 URL 匹配和路由提供了标准、简洁且高性能的原生解决方案。过去开发者需使用复杂的正则表达式或第三方库来解析和提取 URL 参数，而 URLPattern 使得这些操作更清晰、可维护且无需额外依赖。

1. URLPattern 基础与核心概念
• 介绍 URLPattern API 的推出背景：取代传统正则匹配与第三方路由库。
• 提供新 URLPattern 接口，可通过 .test() 与 .exec() 操作直接匹配并提取参数。

2. 基本 URL 模式匹配
• 对比旧方法（URL + 正则）与新 API 的简化写法。
• 展示匹配 /users/:id 的例子，体现代码可读性和简洁性。

3. 提取动态参数（Dynamic Parameters）
• 传统方法依赖匿名的正则捕获组，易出错。
• URLPattern 支持命名参数，可通过结构化对象获取（如 result.pathname.groups）。
• 示例：提取书籍分类 category 与 id。

4. 复合匹配（Compose Multipart Matches）
• 传统方式需多处判断主机名与路径。
• URLPattern 原生支持同时匹配多个部分，例如 hostname + pathname。
• 示例：匹配 .cdn.com 下的 /images/ 文件。

5. 减少项目依赖（Project Dependencies）
• URLPattern 是内置能力，无需加载第三方库，减少 bundle 体积与维护成本。
• 使用浏览器原生实现，跨引擎一致且性能更优。

6. 深度用法详解（Detailed Usage）
• 多种典型场景：
• 路径匹配与参数提取：示例 /products/:category/:id 展示 .test() 与 .exec() 双用法。
• 匹配子域名与版本号：支持在 hostname 层定义变量如 :subdomain.myapp.com，适用于多子域架构。
• 通配符与正则表达式结合：通过 * 和嵌入式正则增强匹配灵活度，如 /users/:userId(d+)/assets/*.(jpg|png|gif)。

7. 实战示例：Service Worker 路由
• 利用 URLPattern 拦截 fetch 事件，根据路径实行不同缓存策略。
• 示例：
• /images/* 采用缓存优先；
• /api/* 使用网络优先。
• 显示该 API 在渐进式 Web 应用（PWA）中的现实意义。

8. 结语与扩展阅读
• URLPattern 提升代码可维护性，简化路由逻辑。
• 推荐进一步查阅 MDN Web Docs 了解完整参考。

web.dev

URLPattern is now Baseline Newly available  |  Blog  |  web.dev

URLPattern became Baseline Newly available as of September 15, 2025.

AI 摘要：ChatGPT Atlas 是 OpenAI 推出的智能浏览器，将 ChatGPT 深度整合进网页使用场景，使 AI 能理解网页内容、保留浏览记忆、自动执行任务。用户在浏览时可直接与 ChatGPT 对话、分析网页或完成操作，无需切换应用。它支持可控的记忆功能（memory）、智能代理模式（agent mode）、隐私与家长管理等，旨在打造一个安全且高效的网页工作助手。目前支持 macOS，Windows 与移动版即将推出。

Openai

Introducing ChatGPT Atlas

The browser with ChatGPT built in.

AI 摘要：本文介绍了 Chrome 新发布的 DevTools MCP 服务，它通过 Model Context Protocol (MCP) 将大型语言模型 (LLM) 与 Chrome DevTools 连接，使 AI 编程助手能够实时调试网页、诊断错误、模拟用户操作、分析性能问题等，从而提升生成代码的可用性和准确性。文章同时提供了使用场景示例、配置方法以及社区参与途径。

1. 背景与意义
• AI 编程助手生成代码时往往无法看到运行效果，相当于“蒙着眼睛编程”。
• Chrome DevTools MCP 服务解决了这一问题，直接让 AI 编程助手接入浏览器调试环境。

2. Model Context Protocol (MCP) 概述
• MCP 是一个开源标准，用于连接大型语言模型 (LLM) 与外部工具和数据源。
• Chrome DevTools MCP server 将调试与性能分析能力引入 AI agent。
• 示例工具：performance_start_trace，可自动启动 Chrome 并记录性能数据以供分析。

3. 应用场景与示例
• 实时验证代码修改：AI agent 可直接在浏览器中确认修改是否生效。
• 诊断网络与控制台错误：AI 可检查网络请求和日志，排查如 CORS 问题。
• 模拟用户行为：自动执行表单填写、点击测试，复现功能性 bug。
• 调试样式与布局问题：实时检查 DOM 和 CSS，解决复杂样式错误。
• 自动化性能审计：运行性能追踪，分析如 LCP (Largest Contentful Paint) 等指标。

4. 使用与配置方法
• 配置方式：在 MCP client 中添加 chrome-devtools 服务。
• 测试示例：运行 prompt "Please check the LCP of web.dev."。
• 更多工具参考：见 tool reference documentation。

5. 社区参与与后续发展
• 当前为公测版本，功能会逐步增加。
• 欢迎开发者与厂商反馈需求与问题。
• 参与方式：通过 GitHub issue 提交建议或 bug。

Chrome for Developers

Chrome DevTools (MCP) for your AI agent  |  Blog  |  Chrome for Developers

Public preview for the new Chrome DevTools MCP server, bringing the power of Chrome DevTools to AI coding assistants.

AI 摘要：本文从浏览器为何要限制 JavaScript 定时器 (setTimeout、setInterval 等) 的触发频率谈起，分析了其背后的性能与电池保护原因，并通过实验对比了不同的替代方案（MessageChannel、window.postMessage、scheduler.postTask 等）的性能表现。作者得出结论，scheduler.postTask 是最理想的方案，并进一步探讨了浏览器设计在“开发者自由 vs 用户体验保护”之间的平衡。

[以下是方便搜索索引的大纲(AI 生成)，请读原文]
1. 背景与问题提出
• setTimeout(0) 实际上存在 4ms 的强制延迟 (clamping)
• 浏览器通过限制 (throttling) 避免过度消耗电量与降低交互体验
• 不同浏览器和环境对 setTimeout 的限制程度不同（例如后台标签页可达 1 秒，Safari 更严格）

2. 定时器替代方案的演进
• setImmediate：已废弃，仅存在于 IE/旧版 Edge
• MessageChannel.postMessage：常见 hack，但 Safari 有额外限制
• window.postMessage：性能较好，但可能与页面其他脚本冲突
• scheduler.postTask：新兴 API，表现最佳，且与浏览器渲染管线更契合

3. 实验与性能测试
• 测试方法：不同浏览器下运行 101 次迭代，测量定时器延迟
• 结果发现：
• Chrome 和 Firefox 的 setTimeout 明显受 4ms 限制
• Safari 对 setTimeout 和 MessageChannel 的限制更重
• scheduler.postTask 在 Chrome/Firefox 下表现优异
• fake-indexeddb 采用的最佳方案：优先 scheduler.postTask，降级 MessageChannel 或 window.postMessage

4. 浏览器设计哲学与开发者困境
• 设计者分为两派：
• 一派主张强制限制 API 防止开发者“自作聪明”导致性能恶化
• 另一派主张提供灵活 API，让开发者自负责任
• W3C 优先级原则：始终将用户体验放在开发者需求之上
• Scheduler API 的出现，体现了两派的折中：给开发者更精细的任务控制，但仍保持与浏览器渲染流程一致

5. 未来展望与风险
• 目前 postTask/postMessage 暂未遭到限制
• 但若开发者滥用（如滥用高优先级任务），未来也可能被浏览器进一步干预
• 文章提醒开发者谨慎选用 API，避免“自找麻烦”

AI 摘要：作者指出在 beforeunload/unload 里用 XMLHttpRequest 或 fetch 上报并不可靠，因为浏览器不会为脚本阻塞卸载流程，网络请求易被取消；推荐使用信标接口 (Beacon API) 的 navigator.sendBeacon 进行 fire-and-forget 异步上报：无需回调或 Promise，JS 立即结束，由浏览器后台传输；虽仅支持 POST 且负载很小，但非常适合离开页面、实时埋点与轻量级前后端同步等无需等待响应的场景，文末附 MDN 文档。

1. 问题背景与常见误区
• 用户离开网站不只关闭标签页，也可能修改地址栏或点书签，难以精准用单一事件捕获。
• 常见做法是在 beforeunload/unload 里用 XMLHttpRequest/fetch 上报，但实践中经常不稳定。

2. 为什么 beforeunload 不可靠
• 浏览器不会为执行 JavaScript 而阻塞卸载流程，以免影响用户体验。
• 页面卸载时网络请求可能未发出或被浏览器取消，导致上报丢失。

3. Beacon API 介绍与用法
• 核心调用：navigator.sendBeacon(url, data)；发送后立即返回，无回调或 Promise。
• 特性：fire-and-forget，浏览器接管传输，JS 执行立即结束，内存不被占用。
• 设计目标：在卸载等敏感时机可靠传递小数据。

4. 适用场景
• 页面关闭/跳转时的 analytics 上报、自动登出提示或状态同步。
• 任意时刻的轻量数据同步（如输入草稿、埋点）——无需等待响应即可继续交互。

5. 限制与注意事项
• 仅支持 POST，负载较小，适合“微消息”而非大体量数据。
• 不适用于需要确认响应、复杂重试或事务保证的场景；这类应选用 fetch/XHR 并在交互上做等待或队列重试。

6. 参考链接
• Beacon API - MDN

hemath.dev

Say bye with JavaScript Beacon

Send data, say goodbye, and move on. That's JavaScript's Beacon in one line.

AI 摘要：作者系统性批判当代 Web 前端栈：DOM 与 HTML 停滞且臃肿、CSS 默认“自内向外”的布局心智与现代应用需求脱节，SVG 与 CSS 相互羡慕却难以统一；“HTML in Canvas”方向治标不治本。作者主张打开更低层的布局、文本与渲染原语，重构视图树与渲染树，以更小更清晰的数据模型拥抱多线程、多来源与异步的新时代，WebGPU 等新基建可成为更简洁的 UI 基元。

1. DOM/HTML 的困境与技术债
• DOM 膨胀失控：仅 Chrome 的 document.body 就有 350+ 键，style 内还有 660 个 CSS 属性；属性/方法边界模糊，部分 getter 触发布局抖动，遗留 onevent 成堆。
• 字符串类型负担：源自 SGML/XML 的“stringly typed”设计让 Web Components 等原生组件 API 笨重，Shadow DOM 引入额外嵌套/作用域，生态接受度低。
• 语义 HTML 的失约：十多年无实质演进，ARIA 兜底本应由语义标签承担的职责；常见结构（如 thread/comment）缺位，WHATWG 更多是边角“本轮加一圈”而非愿景驱动。
• 可编辑性鸡肋：contentEditable 实用化困难重重，富文本编辑器团队“血泪史”常谈。
• 应用现实的“拼装学”：为了做应用 UI，团队被迫以 HTML/CSS/SVG 套娃，承担滚动吸底、虚拟化列表/表格、右键菜单、查找等重复造轮子；UI 与“流式内容”的早期融合如今反成负担。

2. CSS 的本质：自外向内 vs 自内向外
• 正确心智模型：CSS 本质是“两次约束传播”——先自外向内分配可用空间，再自内向外回收实际尺寸；默认是文档导向的“自内向外”，需要手动从 body{height: 100%} 开始把约束往下传，所以“垂直对齐难”并非错觉。
• Flex 的代价与补药：Flex 通过测“自然尺寸”再伸缩，导致递归式“猜测布局”；深度嵌套和未知内容可能引发不可预期放大。可用 contain: size、明确 flex-basis、will-change 等打断全局约束，避免连锁反应。
• API 设计反思：理想的布局系统应把“容器行为”（自外向内）与“放置模型”（自内向外）作为可组合的正交维度提供，而非在单一语法下不断加“抑制/隔离”开关。

3. “好部分”与跨模型错配
• 可用但不优雅：Flexbox、Grid 在理解边界条件后“够用”，但语法“很 CSS”；若从零设计，不会做成今天这种减法式 API。
• 两种系统被硬绑：CSS 同时承担“文本样式的继承系统”和“盒模型布局系统”，前者需继承（如字体），后者主要是包含关系，级联语义不一致，合在一起是历史事故。
• 单位与像素：相对 em 的早期理念已式微，逻辑像素 vs 设备像素更符合用户预期。
• 与 SVG 的“互相羡慕”：SVG 既非 CSS 子集也非超集，变换模型等细节不同；CSS 想要曲线、遮罩、渐变、滤镜，却远不如 SVG 强；开发者在 HTML/CSS 与 SVG 间反复取舍。
• 三个“卡点范例”：
• 文本省略号 text-ellipsis 仅能裁单行不换行文本，段落裁切/检测截断与文本测量 API 皆孱弱。
• 粘性定位 position: sticky 想实现“无条件吸附”需多层荒诞嵌套，本应易如反掌。
• z-index 战争：绝对层级导致“+1/-1 拼数值”，缺少相对 Z 定位的语义。

4. “HTML in Canvas”的误区
• 设计目标错位：为“可编程渲染”而把 HTML 绘进 canvas，结果依旧被 DOM 裹挟（需作为 <canvas> 子树参与布局/样式/无障碍），离真正的可编程 UI 还很远。
• 交互负担转嫁：为了自定义外观，被迫全权接管命中测试 (hit-testing) 与事件，且仅有 2D 命中测试；在已有 CSS 3D 变换环境下显得荒诞。
• Reactivity 风险：让 canvas 回写/观察同一文档树，带来循环依赖与观察者复杂度。
• 文本与字体的“原罪”：Canvas 缺少系统字体、文本布局 API、Unicode 分词/换行等基础能力——真正的难题没有开放正确的底层原语。
• 本质诉求：不是“把 DOM 截图画出来”，而是要打开文本测量、命中测试、可编程布局、统一滤镜/着色器等低层 API；用 DOM 当黑盒无法解决 1990 年代 UI 水平的缺口。

5. 向下开口：重塑视图树与渲染树
• 方向样例：Use.GPU 的“类 HTML 渲染器”在 WebGPU 上实现 X/Y Flex，垂直居中与定位直观，无语义 HTML 或级联，仅“一级公民”的布局；给“div”挂着色器，90% DOM 功能以少量清晰原语重做可达。
• 核心问题重问：视图树应长什么样？如何降解成渲染树？当下是如何被“历史包袱”强行降解的？
• 新引擎机会：Servo、Ladybird 等新浏览器实现轻装上阵，更适合提出新提案；大厂亦可为之，但“品味与自小做起”的工程哲学重要。
• 进程/线程与安全现实：因 Spectre 等 CPU 攻击，SharedArrayBuffer 与 Web Worker 的多线程之路受阻；DOM 若重塑，可与多进程、跨来源隔离、结构化并发、所有权语义、函数式效果 (FP effects) 等现代模型同频共振。
• 最小第一步：以更小更干净的数据模型替换当前“每节点 350+ 属性”的怪物；别误以为问题不可解，关键在于抽丝剥茧、回到正确的内核抽象。

AI 摘要仅供参考和导读和索引，其中可能有失实部分，推荐自行阅读原文。

Acko.net

HTML is Dead, Long Live HTML

Rethinking DOM from first principles

AI 摘要：Chrome 和 Edge 团队宣布 CSS Masonry 布局已在 Chrome/Edge 140 中开放开发者测试。这种新的 CSS 布局模式旨在更有效地创建类似砖块的自适应内容排列，弥补了 CSS Grid、Flexbox 和 Multi-column 的不足。文章详细介绍了 Masonry 的概念、与现有布局的对比、两种正在讨论的语法提案，并提供了如何启用和使用该功能的具体代码示例，鼓励开发者积极测试并提供反馈，以帮助最终确定其 API 设计。

1. 社区动态
• 发布与反馈征集：Microsoft Edge 和 Google Chrome 团队宣布 CSS Masonry 已在 Chrome 和 Edge 140 中开放早期开发者测试，并强调开发者反馈对完善规范和语法的重要性。
• 如何测试：详细说明了在 Chromium 浏览器（Chrome 或 Edge 140+）中通过 about:flags 页面启用 "CSS Masonry Layout" 实验性功能的步骤。
2. CSS Masonry 概述
• 什么是 Masonry：解释了 Masonry 布局模式能够创建类似砖块的紧凑排列，与 CSS Grid、Flexbox 或 Multi-column 不同，它在某个方向上不严格定义轨道，允许内容项自动填充可用空间，特别适用于视觉密集型页面。
• 现有方案及局限性：指出现有通过 JavaScript 库或 CSS Grid/Flexbox/Multi-column 模拟 Masonry 的方法存在性能问题、代码复杂、维护困难以及无法完美实现 Masonry 特性等局限性。
• CSS Masonry 的现状：介绍了 CSS 工作组正在《CSS Grid Level 3》规范中起草 Masonry，并讨论了两种正在考虑的语法提案：独立的 display: masonry 和集成到 CSS Grid 中的 grid-template-*: masonry。
3. 使用 CSS Masonry
• 创建 Masonry 容器：通过代码示例展示了如何使用 display: masonry 和 grid-template-columns 或 grid-template-rows 来创建列式或行式的 Masonry 容器。
• 使用默认轨道尺寸：介绍了 Chromium 实现中 Masonry 的新默认轨道尺寸 repeat(auto-fill, auto)，允许在不明确定义轨道尺寸的情况下创建美观的 Masonry 布局。
• 尝试 Masonry 缩写属性：介绍了正在讨论中的 masonry 缩写属性，可用于同时定义 Masonry 方向和轨道定义，简化了语法。
• 自定义轨道尺寸：展示了 Masonry 在定义不同数量和大小的布局轨道方面的灵活性。
• 跨越多轨道：说明了内容项可以跨越多个轨道，这对于突出重要内容或实现全宽布局非常有用。
• 微调项目放置：介绍了 item-tolerance（原名 item-slack）属性，用于控制项目放置的敏感度，使其更好地匹配源顺序或布局需求。
• 其他可用属性：提到 Masonry 容器可以与 CSS Grid 的其他属性（如 grid-row、grid-column、order 等）结合使用。
4. 反馈与展望
• 呼吁开发者反馈：再次鼓励开发者通过 demos、源代 码和实际应用来测试 Masonry，并通过评论相关 Issue 或在社交媒体上分享反馈，以帮助塑造最终的 API。
• 已知限制：列举了当前 Chromium 实现中存在的已知限制，包括密集填充、反向放置、子网格支持、DevTools 支持等，并鼓励开发者报告 Bug。

Chrome for Developers

Brick by brick: Help us build CSS Masonry  |  Blog  |  Chrome for Developers

Help test the proposed masonry syntax in Chromium.

AI 摘要：Chrome 139 正在实验 Open UI 提出的 Interest Invoker API，该 API 旨在通过声明式 HTML，无需 JavaScript 即可创建鼠标悬停触发的弹出界面，如工具提示和悬浮菜单。它通过 interestfor 属性关联触发器和作为 popover 的目标元素。文章详细探讨了触发器和目标元素的用法、不同 popover 类型的影响、相关的 JavaScript 事件、以及通过 interest-show-delay 和 interest-hide-delay 等 CSS 属性控制的“兴趣延迟”。同时，它也深入讨论了键盘和屏幕阅读器用户的可访问性支持，并指出该 API 虽处于早期实验阶段，但有望极大简化此类 UI 的开发，尽管在某些 popover 行为和触屏交互上仍有待完善。

CSS-Tricks

A First Look at the Interest Invoker API (for Hover-Triggered Popovers) | CSS-Tricks

Chrome 139 is experimenting with Open UI’s proposed Interest Invoker API, which would be used to create tooltips, hover menus, hover cards, quick actions, and other types of UIs for showing more information with hover interactions.

AI 摘要：本文详细探讨了苹果公司对第三方浏览器引擎在 iOS 上的限制，即使在欧盟《数字市场法案》（DMA）生效后，苹果依然通过技术和合同障碍阻止其他浏览器厂商在欧盟成功部署自己的引擎。文章指出苹果此举是为了保护其高利润产品 Safari 及其与谷歌的搜索引擎收入，同时限制网页应用（Web Apps）与原生应用的竞争能力，损害消费者和开发者的利益。作者呼吁欧盟委员会采取强制措施，确保苹果真正遵守 DMA，开放浏览器引擎竞争。

Open Web Advocacy

Apple's Browser Engine Ban Persists, Even Under the DMA - Open Web Advocacy

AI 摘要：本文详细介绍了 Chrome 在 Apple Silicon Macs 上推出的 Skia 新光栅化后端 Graphite。Graphite 是一个面向未来的图形渲染技术，显著提升了 Chrome 在 Motionmark 1.3 测试中的表现，同时为未来的图形改进奠定了基础。通过支持现代图形 API（如 Metal、Vulkan 和 D3D12）、多线程设计以及深度测试等创新技术，Graphite 不仅提高了渲染性能，还优化了用户体验，减少了滚动卡顿和页面加载等待时间。

1. Skia 在 Chrome 中的历史：
• 介绍了 Skia 作为 Chrome 图形渲染核心的历史，从最初的性能问题到引入 GPU 加速后端 Ganesh。
• Ganesh 虽性能优异，但因其以 OpenGL 为中心的设计，难以充分利用现代图形 API 的优势，因此团队开发了 Graphite。

2. Graphite 的成果：
• 在 Macbook Pro M3 上，Motionmark 1.3 得分提升近 15%。
• 优化了真实世界指标，如交互到下一帧时间（INP）、最大内容绘制时间（LCP）、图形流畅度（掉帧百分比）以及 GPU 内存使用等。

3. Graphite 与 Ganesh 的区别：
• 现代图形 API：Graphite 利用 Chrome 的 WebGPU 实现 Dawn，支持 Metal、Vulkan 等现代 API，减少维护负担并提升多线程和 GPU 计算能力。
• 2D 深度测试：通过深度测试减少过度绘制（overdraw），优化不透明和半透明对象的渲染顺序，提升性能并降低移动设备功耗。
• 多线程设计：Graphite 的 API 支持多线程，利用独立记录器（Recorders）在多线程上生成记录（Recordings），减轻主线程负担，减少卡顿和延迟。
• 性能悬崖与管线编译：Graphite 减少渲染管线数量，避免因管线编译导致的卡顿，确保复杂内容与简单内容渲染效率一致。

4. 未来计划：
• 多线程光栅化：计划将光栅化任务分配到多线程，进一步提升性能。
• 减少简单内容的 GPU 内存：通过重新发布记录（Recordings）优化滚动，减少不必要的 GPU 内存分配。
• GPU 计算路径光栅化：探索 GPU 计算路径光栅化技术，提升视觉质量和性能，替代传统的 MSAA 和 CPU 光栅化。

AI 摘要：这篇文章探讨了如何通过Chrome扩展实现浏览器可信事件和网页离线PDF导出。首先，作者介绍了使用Chrome DevTools Protocol协议与浏览器进行交互，以实现自动化任务，比如复制和粘贴操作。文章详细描述了如何在扩展中模拟用户操作以绕过浏览器的安全限制，通过注入脚本和使用DevTools Protocol模拟按键事件，实现内容的选中和复制。接着，作者探讨了如何通过该协议实现网页的PDF导出，利用Page.printToPDF方法生成自定义的PDF文件，并通过扩展的下载API实现自动下载。文中还提供了具体的代码示例和调试方法，帮助开发者实现这些功能。

讨论社区