前端前線 2026 年 6 月 3 日

2026-06-03 — Chrome 149 CSS gap decorations、HTML-in-Canvas API 與 WebMCP

primary=https://developer.chrome.com/release-notes/149 primary=https://developer.chrome.com/blog/gap-decorations-stable primary=https://www.w3.org/TR/css-gaps-1/ primary=https://developer.chrome.com/blog/chrome-at-io26 primary=https://developer.chrome.com/blog/html-in-canvas-origin-trial primary=https://developer.chrome.com/blog/chrome-two-week-release

Chrome 149 穩定版:CSS gap decorations 正式落地、BFCache 支援 WebSocket 連線頁面

Chrome for Developers · 2026-06-02

Chrome 149 於 2026 年 6 月 2 日推送至穩定通道,適用 Android、ChromeOS、Linux、macOS 與 Windows。此版本在 Web 平台層面帶來三項顯著改動:CSS gap decorations 正式可用、Back/Forward Cache 擴展至含 WebSocket 連線的頁面,以及 element.scrollTo() 回傳 Promise。

核心改動

CSS Gap Decorations(W3C 規格:css-gaps-1)讓開發者得以直接在 grid、flexbox 與 multi-column 的間隙(gap)上繪製線條,無需再依靠 border 或偽元素繞道。新屬性包含 column-rulerow-rule 家族,以及控制延伸深度的 column-rule-inset/row-rule-inset;後兩者可搭配 -cap(端點無交叉時)與 -junction(交叉點)子值,精確控制每段裝飾線的內縮量。此外,column-rule-visibility-itemsrow-rule-visibility-items 讓開發者指定哪些軌道間隙要顯示裝飾線。重複語法支援 repeat(),可沿不同間隙交替設定不同顏色或線型,與 grid-template-columns 的語感一致。規格草案同時確認 rule width、color 與 inset 三個屬性均可動畫化。

BFCache WebSocket 支援解除了一項長期限制:過去只要頁面持有開放的 WebSocket 連線,就無法進入 back/forward cache,導致 Notion、Figma、Slack Web 等大型 SPA 的返回導航必須重新載入。Chrome 149 透過在頁面進入 bfcache 時先行靜默斷開 WebSocket,待還原時重連,使這類頁面得以受益。

element.scrollTo() 回傳 Promise 是一項小但實用的 API 填補:開發者現可 await container.scrollTo({ top: 500, behavior: 'smooth' }),在動畫完成後才執行後續邏輯,不再需要 scroll 事件監聽器或 setTimeout 推估。

其他值得注意的異動

  • CSS shape-outsidepath()shape() 函式現已支援矩形座標浮動排除區域。
  • WebAssembly 自訂描述子物件:可替 Wasm 型別關聯 prototype,讓 Wasm 物件方法可從 JavaScript 透過原型鏈呼叫。
  • text-overflow: ellipsis 互動:使用者與省略文字互動時,暫時切換為 clip 模式以顯示完整內容。

影響範圍

CSS gap decorations 最終進入穩定版,讓 Chrome 與 Edge 149 成為首批支援此功能的瀏覽器。Firefox 與 Safari 的實作進度尚未宣布,因此目前需要 @supports 或 progressive enhancement 策略。BFCache WebSocket 支援則對採用即時連線的 Web 應用影響深遠,返回導航效能可望大幅提升。

原始來源:Chrome 149 Release NotesGap Decorations StableCSS Gap Decorations Module Level 1


Google I/O 2026:HTML-in-Canvas API 與 WebMCP 讓 Web 成為 AI Agent 的一等公民

Chrome for Developers · 2026-05-22

2026 年 Google I/O 的 Chrome 議程圍繞著一個核心主軸:讓瀏覽器原生具備供 AI Agent 操作的結構化介面。兩項最具技術深度的發表分別是 HTML-in-Canvas API(已進入 Origin Trial,於 Chrome 149 啟用)與 WebMCP(同樣在 Chrome 149 開始 Origin Trial)。

HTML-in-Canvas API

HTML-in-Canvas 解決了一個存在二十年的問題:Canvas(2D context、WebGL、WebGPU)與 DOM 長期以來形成兩個互不相通的渲染世界。開發者若想在 3D 場景中嵌入文字、表單或可聚焦元素,要麼複製 DOM 至 <foreignObject> 再截圖,要麼用 Canvas 重新繪製 HTML 外觀——兩種方法都失去無障礙支援、瀏覽器翻譯、自動填入等原生能力。

新 API 採用宣告式語法,允許開發者把真實的 DOM 節點繪製至 2D context、WebGL texture 或 WebGPU texture。被嵌入的節點保留 find-in-page、dark mode、DevTools 檢視、ARIA 樹等全部瀏覽器整合能力。Canvas 的坐標系與 DOM 的 getBoundingClientRect 之間的映射由瀏覽器管理,事件命中測試也相應更新。Origin Trial 文件發布於 developer.chrome.com/blog/html-in-canvas-origin-trial

WebMCP:為 AI Agent 公開結構化工具

WebMCP 是一項開放 Web 標準提案,讓網站以機器可讀的格式聲明「這個頁面支援哪些操作」——類似 robots.txt,但針對 AI 工具調用而非爬蟲抓取。網站可透過 JavaScript API 登錄具名函式或 HTML 表單作為「工具」,瀏覽器內的 AI Agent(如 Chrome 的 Gemini 整合)便可直接呼叫,無需螢幕截圖解析或 DOM 盲目點擊。

WebMCP 原型在 Chrome 149 以 Origin Trial 形式向開發者開放,配套文件於 2026 年 5 月 18 日發布。與 HTML-in-Canvas 結合後,Canvas 驅動的應用程式成為 Agent 可直接操作的一等介面——Agent 不再需要「看圖猜按鈕」,而是呼叫已宣告的工具方法。

影響範圍

Chrome 同時宣布將發布週期從四週縮短為兩週,從 Chrome 149 後的版本起實施。這意味著 web 平台功能的迭代節奏加快一倍,但也對瀏覽器延伸套件相容性測試與企業凍結版本管理帶來挑戰。WebMCP 尚未進入任何 WHATWG 或 W3C 正式規格流程,目前仍是 Google 提案;Firefox 與 Safari 的立場尚未表明。

原始來源:Chrome at I/O 2026HTML-in-Canvas Origin TrialChrome Two-Week Release Cycle


End of article
0
Would love your thoughts, please comment.x
()
x