發布日期：2025 年 10 月 29 日
除非另有說明，否則這些變更適用於 Android、ChromeOS、Linux、macOS 和 Windows 的 Chrome 143 Beta 版。如要進一步瞭解這些功能，請點選提供的連結或前往 ChromeStatus.com。如要下載 Chrome 143 Beta 版，請前往 Google.com (適用於電腦) 或 Google Play 商店 (適用於 Android)。
CSS 和 UI
CSS 錨定後備容器查詢
這項功能會根據套用的 position-try-fallbacks 值，推出 @container anchored(fallback) 來設定錨定位置元素後代的樣式。
舉例來說，您可以根據錨點和錨定元素彼此的相對位置，使用這類查詢來設定錨定元素的繫結或動畫樣式。
範例：
#anchored {
position-try-options: flip-block;
container-type: anchored;
}
@container anchored(fallback: flip-block) {
#anchored > .arrow {
--arrow-rotation: 180deg;
}
}
詳情請參閱「Detect fallback positions with anchored container queries from Chrome 143」。
EditContext：TextFormat underlineStyle 和 underlineThickness
Chromium 隨附的 EditContext API 有一項錯誤，即 EditContext/textformatupdate_event 提供的 TextFormat 物件，會為 underlineStyle 和 underlineThickness 屬性提供不正確的值。在 Chromium 中，可能的值為 None、Solid、Dotted、Dashed、Squiggle 和 None、Thin、Thick。不過，根據 EditContext 規格，這些值應為 none、solid、dotted、dashed、wavy 和 none、thin、thick。
網站 API
允許在 JavaScript DOM API 中使用更多字元
HTML 剖析器一向 (或長期以來) 允許元素和屬性使用各種有效字元和名稱，但用來建立相同元素和屬性的 JavaScript DOM API 則較為嚴格，與剖析器不符。
這項變更會放寬 JavaScript DOM API 的驗證，以符合 HTML 剖析器。
詳情請參閱： github.com/whatwg/dom/issues/849
這項變更不會造成相容性問題，因為先前允許的所有元素和屬性名稱，在新行為中仍有效。
推測規則：改善行動裝置的「急切」急切度
在行動裝置上，如果 HTML 錨點元素在可視區域中停留短暫時間，系統現在會觸發「急切」急切度的預先擷取和預先算繪推測規則。
先前，預先擷取和預先算繪會盡快啟動，相當於「立即」急切度。更新後的行為更實用，因為它更能反映作者的意圖，比「中等」更急切，但比「立即」不急切。
實作 CSS 屬性 font-language-override
這項功能在 Chromium 中導入了對 font-language-override CSS 屬性的支援。開發人員可透過這個屬性，直接在 CSS 中指定四個字元的語言代碼，覆寫用於 OpenType 字元替代的系統語言。
這項功能可提供精細的排版控制，適用於多語言內容或含有特定語言字形變體的字型。
WebGPU：紋理元件重組
紋理元件重組可讓著色器存取紋理的紅色、綠色、藍色或 Alpha 版通道時，重新排列或取代顏色元件。GPUTextureViews
ICU 77 (支援 Unicode 16)
Unicode 支援程式庫 ICU (International Components for Unicode) 從 74.2 版升級至 77.1 版，新增 Unicode 16 支援，並更新語言代碼資料。如果網頁應用程式假設 Intl JavaScript API 會採用特定格式，以下兩項變更可能會造成風險：
- 現在，義大利數字的預設格式會省略 4 位數數字的千位數分隔符。舉例來說，
new Intl.NumberFormat("it").format(1234)會傳回「1234」而非「1.234」。您可以使用Intl.NumberFormat建構函式的useGrouping參數，還原舊版行為。 - 在某些英文地區設定 (例如 en-AU、en-GB 和 en-IN)，完整星期名稱後會加上半形逗號，因此「Saturday 30 April 2011」會變成「Saturday, 30 April 2011」。網頁應用程式應避免依賴日期的精確格式。
- Intl 和 RegExp (V8)：許多小變更。變更為義大利號碼格式的風險最高，因此設有專屬標記。
- IDNA：這項升級通常可支援更多項目，並提升 WPT 的整體測試結果。
- 文字區隔：最明顯的變化是使用
word-break: auto-phrase時，日文換行效果有所提升。這與 https://chromestatus.com/feature/5133892532568064 有關。
DataTransfer 屬性，適用於 insertFromPaste、insertFromDrop 和 insertReplacementText 輸入事件
這項功能會使用 insertFromPaste、insertFromDrop 和 insertReplacementText 的 inputType，填入輸入事件的 dataTransfer 屬性。在 contenteditable 元素中進行編輯作業時，可存取剪貼簿和拖曳資料。
dataTransfer 物件包含 beforeinput 事件期間提供的相同資料。
這項功能僅適用於 contenteditable 元素。對於表單控制項 (textarea、input)，行為維持不變，data 屬性包含插入的文字，而 dataTransfer 仍為空值。Safari 和 Firefox 都已支援這項功能。Chrome 採用這項功能後，可提升瀏覽器互通性，為網頁作者提供更一致的體驗。
FedCM - 支援 IdP 的結構化 JSON 回應
這項功能可讓識別資訊提供者 (IdP) 透過 id_assertion_endpoint，將結構化 JSON 物件傳回給信賴方 (RP)，而非純字串。
這項變更可讓開發人員不必手動序列化及剖析 JSON 字串，進而簡化整合程序。這項功能提供更動態且彈性的驗證流程，讓 RP 直接解讀複雜的回應，並支援 OAuth2、OIDC 或 IndieAuth 等各種通訊協定，無須頻外協議。
WebTransport 應用程式通訊協定交涉
WebTransport 應用程式通訊協定交涉功能可讓您在 WebTransport 握手期間，交涉網路應用程式使用的通訊協定。
建構 WebTransport 物件時，網頁應用程式可以指定應用程式通訊協定清單。這些通訊協定隨後會透過 HTTP 標頭傳達至伺服器。如果伺服器選擇其中一種通訊協定，可以在回應標頭中指出，且回覆內容會顯示在 WebTransport 物件中。
適用於隔離網頁應用程式的 Web Smart Card API
僅適用於隔離網頁應用程式 (IWA)。這項功能可讓智慧卡 (PC/SC) 應用程式移至 Web 平台。讓他們存取主機作業系統提供的 PC/SC 實作項目 (和讀卡機驅動程式)。
管理員可以透過下列兩種方式控管這項 API 的可用性：
- 全域：使用
DefaultSmartCardConnectSetting政策 - 依應用程式設定：使用
SmartCardConnectAllowedForUrls和SmartCardConnectBlockedForUrls政策
網頁應用程式資訊清單：指定更新資格，圖示網址為 Cache-Control: immutable
資訊清單規格現在包含更新資格演算法。這項功能可讓更新程序更具決定性及可預測性，開發人員能進一步控管更新套用至現有安裝項目的時間，使用者也能選擇如何處理更新，例如選擇忽略更新。此外，這項標頭還可移除使用者代理程式為避免浪費網路資源而實作的「更新檢查節流」。
高耗能廣告干預：傳送至嵌入框架的報表
除了廣告框架本身，廣告干預報表現在也會傳送至廣告的嵌入框架。傳送至嵌入影格的報表會包含廣告 iframe 的 ID，以及在報表主體訊息欄位中卸載的影格預先重新導向網址。這項異動可讓嵌入情境識別有問題的廣告供應商，並處理干擾性廣告，進而提升使用者體驗。
進行中的來源試用
在 Chrome 143 中，您可以選擇加入下列新的原始碼試用計畫。
Digital Credentials API (支援核發)
這項功能可讓發行網站 (例如大學、政府機構或銀行) 安全地啟動數位憑證的佈建 (發行) 程序，直接將憑證發行到使用者的行動錢包應用程式。在 Android 上，這項功能會使用 Android IdentityCredential CredMan 系統 (Credential Manager)。在桌機上，系統會使用 CTAP 通訊協定，採取跨裝置方法，類似於數位憑證的跨裝置呈現流程。
TCP 通訊端集區限制隨機化
只要利用 Chrome 連線集區大小的限制，您就能取得原本無法存取的跨網站狀態資訊。具體來說，您可以 (以某種程度的統計確定性) 評估登入狀態、瀏覽記錄，甚至是更具體的內容，例如 Gmail 收件匣中是否有待處理的郵件。
為減輕這項問題，我們在限制 TCP Socket 集區的方式中加入隨機性，讓觀察網站無法以高確定度推斷這項資訊。
淘汰和移除
這個版本的 Chrome 會淘汰及移除下列章節中的項目。如需計畫淘汰、目前淘汰和先前移除的項目清單，請前往 ChromeStatus.com。
這個版本的 Chrome 會淘汰兩項功能
淘汰 Intl Locale Info 的 Getter
Intl Locale Info API 是 ECMAScript TC39 第 3 階段提案，旨在公開地區設定資訊 (例如一週資料 (一週的第一天、週末開始日、週末結束日、第一週的最小天數) 和地區設定使用的文字方向小時週期)，藉此改善 Intl.Locale 物件。
Chrome 99 版已推出這項實作功能。不過，提案在第 3 階段有所變更，並將多個 getter 移至函式。您必須移除已淘汰的 getter，並重新啟動重新命名的函式。
淘汰 XSLT
XSLT v1.0 於 1999 年標準化，所有瀏覽器都遵循這項標準。在此期間，XSLT 已演進至 v2.0 和 v3.0，新增了多項功能，並與瀏覽器中實作的版本有所不同。由於缺乏進展，加上 JavaScript 程式庫和架構的興起，這些程式庫和架構提供彈性且強大的 DOM 操作，導致用戶端 XSLT 的使用量大幅下降。JavaScript 技術 (例如 JSON 和 React) 大致已取代其在網頁瀏覽器中的角色。
Chromium 會使用 libxslt 程式庫處理這些轉換，但 libxslt 在 2025 年約有六個月未維護。Libxslt 是複雜且歷史悠久的 C 程式碼庫，容易發生記憶體安全漏洞，例如緩衝區溢位，這類問題可能導致任意程式碼執行漏洞。由於用戶端 XSLT 現在是很少使用的利基功能，因此這些程式庫的維護和安全審查次數，比核心 JavaScript 引擎少。不過，這類 API 會直接處理不受信任的網路內容，因此可能成為攻擊目標。事實上，XSLT 是近期幾起備受關注的安全性漏洞的來源，持續對瀏覽器使用者造成風險。
基於上述原因，Chromium 預計從網路平台淘汰並移除 XSLT。WHATWG 決定繼續淘汰 XSLT。
如要進一步瞭解淘汰事宜，以及如果您依賴 XSLT 讀取，該如何因應，請參閱「移除 XSLT，打造更安全的瀏覽器」。