9 月 28 日消息，谷歌 Chrome 106 正式版更新相比 105 變化沒有那么大，但仍然包含一些有趣的功能，還棄用了一些功能。
在谷歌 Chrome 106 中棄用了三個功能。在 requestFileSystem () 方法中不推薦使用持久配額類型，因為給代碼增加了不必要的復(fù)雜性，由于其使用率低，這尤其不受歡迎； HTTP / 2 推送流將遭受同樣的命運，Chrome 將不再接收、存儲在內(nèi)存中或使用此配置發(fā)送的流；同樣，Chrome 106 也放棄了對 cookie 域名屬性中的非 ASCII 字符的支持，以符合 RFC 6265bis 規(guī)范中的最新標(biāo)準(zhǔn)化。
在新功能方面，Chrome 106 一項主要改進是支持 SerialPort 中的自帶緩沖區(qū) (BYOB)。谷歌描述如下：
“開發(fā)人員可以通過調(diào)用 getReader ({mode: 'byob'}) 來檢測對 BYOB 讀取器的支持，因為舊實現(xiàn)在傳遞新參數(shù)時會拋出 TypeError。BYOB（或“自帶緩沖區(qū)”）讀取器允許開發(fā)人員指定讀取數(shù)據(jù)的緩沖區(qū)，而不是為每個塊分配新緩沖區(qū)的流。除了潛在地降低內(nèi)存壓力之外，這還允許開發(fā)人員控制接收到的數(shù)據(jù)量，因為流返回的數(shù)據(jù)量不能超過提供的緩沖區(qū)中空間。從端口讀取特定數(shù)量的數(shù)據(jù)能力使這個 API 對于習(xí)慣于針對串行設(shè)備的 Windows 和 POSIX API 進行編程的開發(fā)人員更加熟悉，這些 API 以同樣的“自帶緩沖區(qū)”原則運行。相比之下，當(dāng)前的 API 要求開發(fā)人員針對多余的不需要的數(shù)據(jù)進行防御性編碼，而不是只讀取他們準(zhǔn)備處理的內(nèi)容。”
除此之外，無前綴 hyphenate-character 屬性 CSS 屬性現(xiàn)在很穩(wěn)定，將隨 Chrome 106 一起提供。“-webkit-hyphenate-character”屬性將在稍后未指定的日期棄用。
Chrome 106 的另一個關(guān)鍵改進是支持 Intl.NumberFormat API v3 。此版本具有以下新功能：
添加 3 個新函數(shù)來格式化數(shù)字范圍：formatRange / formatRangeToParts / selectRange
分組枚舉
新的舍入 / 精度選項
舍入優(yōu)先級
將字符串解釋為小數(shù)
舍入模式
符號顯示為負(fù)
此外，還為 WebCodecs 中的音頻和視頻接口引入了出隊回調(diào)。它允許開發(fā)人員在編碼和解碼接口中找出隊列大小是否減少，而不是設(shè)置定時函數(shù)來隨機檢查相同。
Chrome 106 現(xiàn)在支持 CSS“ic”長度單位。這用于表示日文和中文字體的“相對于水象形文字的高級度量”的長度，并且已經(jīng)存在于 Safari 和 Firefox 中。展望未來，CORS 將通過 Signed HTTP Exchange 在子資源預(yù)取和加載中強制執(zhí)行。
此版本的 Chrome 中也有一些實驗性功能。有兩個開發(fā)者試驗被鎖定在 flag 中。第一個是將文件系統(tǒng)訪問 API 中的異步方法更新為同步方法。這將提高性能并為 API 帶來一致性。其次，谷歌將繼續(xù)其 UA 用戶代理減少計劃的第 5 階段。這個想法是為了提高隱私，同時減少在解析復(fù)雜的 User-Agent 字符串時出錯的機會。
同樣，兩項能力也已進入 Origin 試驗階段。匿名 iframe 提供了一種通過臨時上下文在外部 iframe 中加載文檔的方法。由于它是 Cross-Origin-Embedder-Policy (COEP) 的概括，因此消除支持 COEP 的第三方 iframe 作為嵌入到 COEP 頁面的先決條件的要求。此試用將持續(xù)到 Chrome 108。
現(xiàn)在也通過 Origin 試用版提供彈出式 API，它允許開發(fā)人員在 Web 應(yīng)用程序之上的交互式瞬態(tài) UI 元素。這類似于“對話框”元素，但具有新功能，例如包括光標(biāo)關(guān)閉行為、彈出交互管理、動畫、事件支持和非模態(tài)模式。
接下來是 Chrome 107 瀏覽器，它將于 9 月 29 日進入 Beta 通道，并將于 10 月 25 日進入穩(wěn)定版頻道。
來源：IT之家
