Firefox 157 起預設開啟 JPEG XL，改用 Rust 版解碼器 jxl-rs
Mozilla dev-platform 郵件群組 · 2026-08-24
Mozilla 工程師 Timothy Nikkel 於 2026 年 8 月 24 日在 dev-platform 郵件群組發出 JPEG XL 的 Intent to Ship，計畫在 Firefox 157 讓此圖片格式預設開啟，追蹤編號為 Bugzilla Bug 2065096。此舉緊接在先前針對 AVIF 的支援之後，補齊 Firefox 對新一代影像格式的支援拼圖。JPEG XL 解碼器自 Firefox 152 起已可透過 Firefox Labs 手動開啟，如今準備轉為預設值。
核心改動
此次真正的分水嶺不是「支援 JPEG XL」本身——Nightly 版本先前就已經能解碼——而是 Mozilla 用全新的 Rust 實作 jxl-rs 徹底汰換舊有解碼器。舊解碼器以 C++ 撰寫，程式碼量高達約十萬行，長期是安全稽核的重點對象；jxl-rs 由 Google Research 主導開發，藉助 Rust 的記憶體安全特性大幅降低緩衝區溢位等常見漏洞類型的攻擊面。
控制此功能的偏好設定為 image.jxl.enabled，目前已在 Nightly 頻道預設開啟。效能面上，公告特別提到 jxl-rs 0.6.0 帶來的多執行緒解碼可望讓大型圖片的解碼速度有感提升。功能涵蓋漸進式顯示（progressive rendering）與動畫播放，這兩點都是 Safari 目前尚未支援的部分——Safari 自 17.0 版（2023 年）便已支援 JPEG XL，但缺少漸進式顯示與動畫。
JPEG XL 對應的規格是 ISO/IEC 制定的 ISO/IEC 18181，而非 W3C 或 WHATWG 文件；Mozilla 在 standards-positions 追蹤議題 #522 中將立場標記為「中立」，W3C TAG 的設計審查（#633）則是「有疑慮但可接受」。公告也坦言目前 HDR 圖檔仍會以 SDR 顯示，與 Firefox 既有其他格式的行為一致，尚未解決。
影響範圍
瀏覽器陣營的態勢也在這次公告中一併攤開。Chrome 目前已用同一套 jxl-rs 函式庫在旗標後方實作 JPEG XL，但尚未發出正式的 ship intent；Mozilla 稱先前 Chrome 團隊在 blink-dev 群組的討論中「立下的挑戰」，暗示雙方都在等對方先跨出正式支援的一步。JPEG XL 也被列入 Interop 2026 的調查領域之一，對應的相容性測試專案 web-platform-tests/interop-jpegxl 與其在 wpt.fyi 上的通過率，將是後續三大瀏覽器能否同步支援的觀察指標。
對網站與圖片產線而言，一旦 Firefox 157 落地，JPEG XL 將首次具備三大排版引擎中兩家（Gecko、WebKit）的預設支援，缺口只剩 Blink；已針對 AVIF 做過格式協商（content negotiation）的網站，可望用同一套邏輯加入 JPEG XL 作為候選格式，同時受益於其宣稱的無損壓縮與漸進式載入特性。
原始來源：Mozilla dev-platform: Intent to Ship JPEG XL、Bugzilla Bug 2065096、Mozilla Hacks 報導
HTML 標準精簡具名屬性演算法，改以 named elements 作單一定義來源
WHATWG HTML Standard (GitHub) · 2026-08-24
WHATWG HTML 規格編輯 Anne van Kesteren 於 2026 年 8 月 24 日提交 commit 224e47e，標題為「Editorial: derive document supported property names from named elements」。這是一次 editorial（不影響行為，只重整敘述方式）的規格修訂，目的是消除 document 物件的 supported property names（受支援屬性名稱） 演算法，與 named elements（具名元素） 定義之間長期不一致的手動維護問題。
背景
HTML 規格中，document 上的具名屬性存取行為仰賴兩段各自獨立撰寫的定義：一段列出「哪些屬性名稱受支援」，另一段定義「哪些元素算作具名元素」。這兩段內容靠人工同步、靠留言提醒維持一致，結果隨規格演進逐漸出現落差——例如 依照舊定義仍算是具名元素、名稱為空字串，卻完全不會對 supported property names 產生任何貢獻。這個落差在實務上不會被觀察到，因為 named elements 只會在 Web IDL 已確認某名稱屬於 supported property name 之後才被查詢，但規格文字本身缺乏唯一可信的定義來源。
核心改動
此次修訂把 named elements 提升為唯一定義，並將原本只出現在 supported property names 那段的「非空字串」限制條件一併移入 named elements 定義本身；supported property names 則改為直接由 named elements 推導而來。commit diff 顯示單一檔案 source 增加 19 行、刪除 29 行，淨減少規格文字量。修訂同時調整條列順序，讓 id 屬性排在 name 屬性之前，對應規格原本用文字另外說明「當同一元素同時貢獻 id 與 name 時，id 值排前面」的規則，現在直接反映在定義結構中，不再需要額外文字說明。
這個 commit 的 parent 正是同批修訂中的另一個 commit 6b2778f（移除 object/embed 的 exposed 概念，詳見下一則），兩者由同一位作者、同一次提交時間（committer date 2026-08-24T14:25:03Z）一起送入規格倉庫，可視為一組針對 document 具名屬性演算法的整體重構。
影響範圍
由於這是 editorial 變更，不會改變任何瀏覽器的可觀察行為，四大引擎的實作都不需要跟進程式碼調整。它的價值在於規格可維護性：往後貢獻者或引擎實作者若要理解「一個元素何時會成為 document 上可以用中括號或點記法存取的具名屬性」，只需要讀 named elements 這單一定義，不再需要交叉比對兩段可能悄悄失去同步的文字。
WHATWG HTML 移除 object/embed 具名屬性的「exposed」過濾機制
WHATWG HTML Standard (GitHub) · 2026-08-24
WHATWG HTML 編輯 Anne van Kesteren 於 2026 年 8 月 24 日提交 commit 6b2778f，標題「Remove object/embed exposedness from document named properties」，修訂 document 具名屬性查找演算法，徹底移除「exposed（曝光）」這個概念。此變更修復規格 issue #12787，並附上對應的 web-platform-tests 修正 wpt#62149。
背景
舊規格中， 與 元素要成為 document 的具名屬性，除了要有 id 或 name，還得先通過一個「exposed」判斷：這個判斷依據元素的 fallback content 狀態、是否含有 object/embed 子孫元素、以及是否遞迴地被其他 object 元素包住，來決定該元素是否「曝光」給具名屬性查找與列舉。issue #12787 指出，三大引擎沒有一家真正落實這套規則——Gecko 完全無視 exposed 判斷；Blink 與 WebKit 在具名查找（named property lookup）時忽略 fallback content 狀態，卻在列舉 supported property names 時整個略過 exposedness 判斷，導致 Object.getOwnPropertyNames(document) 可能回傳一個實際存取後卻是 undefined 的屬性名稱。
核心改動
commit 選擇跟隨 Gecko 的既有行為，直接砍掉整個 exposed 演算法，不再嘗試修正 Blink/WebKit 那套「以巢狀關係做近似判斷」的邏輯。commit message 明白指出：/ 的具名屬性是遺留（legacy）功能，為了修正一個邊緣情境去維持額外複雜度並不值得。diff 顯示同一份 source 檔案增加 12 行、刪除 19 行，移除範圍涵蓋 embed、form、iframe、img、object 等元素的具名屬性列表段落中對 exposed 的引用，以及具名屬性查找定義中的對應邏輯，最終讓「exposed」這個詞彙從整份規格中完全消失——這是它在規格中唯一的使用之處。
影響範圍
由於三大引擎原本就沒有一致遵守 exposed 規則，這次修訂更貼近「讓規格描述現況」而非強迫引擎改變行為，預期不會造成現行網站的相容性問題。對 Blink/WebKit 而言，理論上兩者原本「列舉時忽略 exposedness、查找時仍套用 fallback 判斷」的不一致行為，需要對齊到新規格定義的單一（不再過濾）行為，相關斷言已反映在 wpt#62149 的測試修正中。這也是 WHATWG 一貫「以可互通實作為準」的規格維護風格：先觀察多方引擎的實際行為分歧，再由規格收斂到一個各家都容易對齊、且複雜度最低的定義。