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实现自动下载。文中还提供了具体的代码示例和调试方法，帮助开发者实现这些功能。

讨论社区