我看完今年 Google I/O 的整理，腦中第一句話是：「好，又是 AI。」不是說 AI 不重要，只是整場資訊塞得太滿，幾個我真的可能在前端專案用到的 Web Platform 更新反而差點被淹掉。於是我又回頭把清單翻了一次，先把那些華麗 demo 放旁邊，挑出幾個會讓日常 UI 少寫一點 JavaScript 的東西。
Google I/O 2025 公布了不少 Web 新功能，其中一條很明顯的方向是：以前常靠 JavaScript 元件完成的介面，正在慢慢回到瀏覽器原生能力。
像 CSS carousel 可以處理一部分輪播互動，Anchor Positioning 能讓提示框或選單跟著指定元素定位。Baseline 則用比較簡單的標記，告訴開發者某項功能是否已被主要瀏覽器普遍支援。
這不表示我們可以立刻刪掉所有 UI 套件。新功能通常還有瀏覽器版本和細節差異，但至少未來做常見介面時，可以先看看 HTML 和 CSS 是否已經能處理，不必第一時間安裝更多依賴。
我覺得比較值得注意的三件事
-
CSS carousel 把捲動按鈕和位置標記帶進原生 CSS，簡單輪播未必需要一整套 slider。
-
Anchor Positioning 解決浮層跟著按鈕定位的老問題，還能和 popover 一起使用。
-
Baseline 開始出現在更多開發工具，瀏覽器相容性不再只是一長串版本號。
內建 AI API 當然很吸睛，不過目前仍有模型下載、裝置能力和跨瀏覽器支援等限制。相較之下，前面幾個 HTML、CSS 更新比較可能先進入日常專案。新功能很多時，挑出近期真的用得到的，通常比逐條翻譯發表內容更有幫助。
這幾年瀏覽器的更新有點像把常見 UI pattern 收回平台層。原生方案通常能一起處理鍵盤、焦點和效能，但規格成熟需要時間。前端不必追每一個新 API，知道有哪些問題正在被瀏覽器接手，下一次遇到需求時想得起來就很有用了。
我現在看這類大會清單，會刻意分成「今天能用」、「可以漸進增強」和「先記名字」三欄。Baseline 適合判斷第一欄；Anchor Positioning 常能放到第二欄，因為失效時還能退回既有定位；至於裝置端 AI，如果產品沒有明確情境，暫時留在第三欄也完全沒關係。
這樣分類有個好處：團隊不會因為追新而每季重寫元件，也不會等到所有瀏覽器百分之百一致才開始學。平台功能從實驗到普及通常要走一段路，前端工程師真正需要的能力，是知道哪一段風險可以由 fallback 接住，而不是背完整場 keynote。