Chrome 148：CSS 名稱容器查詢、媒體延遲載入與 Prompt API 三項正式登場
Chrome Developers Blog · 2026-05-05
Google 於 2026 年 5 月 5 日發布 Chrome 148，帶來三項對前端開發影響顯著的平台功能：CSS 名稱限定容器查詢（name-only container queries）、<video>/<audio> 的 loading="lazy" 屬性，以及基於 Gemini Nano 的瀏覽器端 Prompt API。
CSS 名稱限定容器查詢
在此之前，CSS 容器查詢必須在宣告 container-name 的同時搭配 container-type，才能讓 @container 規則生效。Chrome 148 移除這項限制，允許只設定名稱即可使容器查詢鎖定特定元素，而不需要同時宣告 inline-size 或 size 類型：
#container {
container-name: --foo;
/* 不需要 container-type: inline-size */
}
@container --foo {
input { background-color: green; }
}這個變更使得設計系統在構建「名稱限定作用域」時更為簡潔，不必為了啟用查詢而改變布局上下文（layout context）。規格層面的說明可參考 CSS Containment Level 3 草稿，此功能已在 Chromium bug tracker 上有完整的 intent-to-ship 記錄。
video 與 audio 元素的 loading="lazy"
延遲載入（lazy loading）此前僅適用於 <img> 和 <iframe>。Chrome 148 將相同的 loading 屬性引入 <video> 與 <audio>，使瀏覽器在媒體元素接近視窗時才開始請求媒體資源：
<video src="demo.mp4" loading="lazy" controls></video>對於媒體密集型頁面（如文章列表夾帶自動播放影片預覽），這項功能可以減少初始頁面載入的網路請求數量，降低資料使用量並縮短 LCP（Largest Contentful Paint）時間。未設定 loading 或設為 eager 的元素行為維持不變。
Prompt API：瀏覽器端大型語言模型存取介面
Chrome 148 將 Prompt API 納入正式 origin trial，提供 JavaScript 直接呼叫瀏覽器內建 Gemini Nano 模型的標準化介面。API 支援文字、圖像、音訊三種輸入類型，並可對輸出格式施加約束——包括正規表達式與 JSON Schema：
- 文字生成（帶系統指令）
- 圖像說明（image captioning）
- 視覺搜尋
- 音訊轉錄與聲音事件分類
- 從多模態內容提取資訊
輸出格式約束讓開發者可以要求模型只輸出合法 JSON，適合在不經過伺服器的情況下做本地端結構化資料提取。Prompt API 是 Chrome 推動 on-device AI 的系列規格之一，與 Translation API 和 Summarizer API 並行。
WAICT：Mozilla 提出瀏覽器端 JavaScript 程式碼完整性與透明度規格
Mozilla Hacks · 2026-05-05
Mozilla 在 Real World Cryptography 2026 聯合發表 WAICT（Web Application Integrity, Consistency and Transparency）提案，目標是讓瀏覽器能夠驗證所執行的 JavaScript 程式碼與開發者公開承諾的內容一致，解決端對端加密應用中伺服器可以靜默替換用戶端程式碼的根本性安全問題。
問題根源
現有 Web 安全模型依賴 TLS 防止傳輸層竄改，但伺服器本身仍可在任何請求中提供惡意版本的 JavaScript，針對特定用戶投遞竄改版本而其他人無從察覺。對於金融、通訊、醫療等應用，這意味著即使聲稱使用端對端加密，程式碼送達用戶端的完整性無法保證。
規格機制
WAICT 定義兩個核心屬性：
- Integrity（完整性）：瀏覽器執行的程式碼必須與開發者在 manifest 中承諾的內容完全相符。
- Transparency（透明性）：這些 manifest 必須公開記錄於可獨立稽核的 append-only log，類似 Certificate Transparency 的機制。
網站透過 HTTP 標頭選擇加入（opt-in），並將用戶端程式碼以密碼學方式綁定到 manifest，再將 manifest 提交至公共 log。瀏覽器在強制執行模式下，遇到不在 log 中的程式碼時直接拒絕執行。
實作狀態
規格儲存庫位於 github.com/waict-wg，Firefox Nightly 已有可運作的原型。示範環境 waict.dev 提供端對端加密視訊通話應用展示整個信任鏈的運作方式。Mozilla 的合作夥伴包括 Cloudflare、Freedom of the Press Foundation 與 Meta，共同制定部署規格。
從技術角度看，WAICT 將 Web 程式碼的可驗證性拉到與 Certificate Transparency 對 TLS 憑證的同等程度——攻擊若不再不可見，便難以持續執行。
原始來源：Mozilla Hacks — Trustworthy JavaScript for the Open Web、WAICT Working Group GitHub
Bun 正式啟動從 Zig 至 Rust 的移植計畫
GitHub / oven-sh/bun · 2026-05-06
Bun JavaScript 執行環境的核心開發者在儲存庫中公開了一份名為 PORTING.md 的文件，詳述將 Bun 底層實作從 Zig 系統性移植到 Rust 的兩階段計畫。這份文件本週在 Lobsters 討論板引發大量討論，原始 PR 分支名稱 claude/phase-a-port 也引起對 AI 輔助移植的猜測。
移植策略
計畫分為 Phase A 與 Phase B：Phase A（草稿）要求建立 .rs 檔案，忠實捕捉 Zig 邏輯，但不需要能夠編譯；Phase B（編譯）再以機械式修正逐一讓各 crate 通過編譯。文件明確要求「比對 Zig 的結構——相同函式名稱、欄位順序、控制流」，禁止使用 tokio、hyper、async-trait 等非同步函式庫，改以回呼與狀態機取代。
架構對應
主要的 crate 對應關係如下：
bun_str：字串處理bun_sys：系統呼叫bun_jsc：JavaScriptCore 引擎整合（保留 FFI 與 unsafe）bun_bundler、bun_js_parser：打包與解析bun_threading、WorkPool：執行緒池
技術挑戰
文件坦承數個困難點。錯誤處理方面，Zig 的 tagged error union 必須轉為 Rust 的 Result<T, bun_core::Error>，同時保留 Copy 語意。並發模型方面，Rust 的 Send/Sync 靜態分析比 Zig 的防禦性加鎖更嚴格，需要逐一審視資料在執行緒間的移動。記憶體配置方面，解析器使用 arena bulk-free 模式，其他地方使用 mimalloc 全域配置器，兩者的生命週期語意截然不同。
封閉集合的 union(enum) dispatch 也需要特別處理——Zig 的 tagged union 模式在 Rust 中若有循環依賴，必須改用 vtable 或提升至父層的 match dispatch。