題干與適用場景
一個跨瀏覽器設計系統希望為支援新 CSS at-rule 的瀏覽器啟用更自然的進入動畫和視圖過渡，同時保留舊瀏覽器的靜態體驗。Chrome 官方 Web UI 更新介紹了在 @supports 中偵測特定 at-rule 的方向。請設計不影響首屏、無障礙和主題一致性的發布方案。
面試官考察點
面試官考察你是否把「語法識別」與「完整行為可用」區分開，能否設計 CSS 層疊、降級、減少動效偏好、伺服器端渲染和監控。高品質回答會避免把瀏覽器名稱硬編碼為能力判斷。
回答前需要釐清的問題
- 增強能力是裝飾性動畫，還是依賴過渡完成的互動狀態？
- 不支援新規則時，最低可接受體驗是什麼？
- 使用者的
prefers-reduced-motion、高對比度和鍵盤操作如何優先？ - 是否需要覆蓋嵌入 WebView、舊版瀏覽器和 SSR 首屏？
30 秒回答
「我會把基礎佈局和狀態互動寫成預設 CSS，再用能力查詢為支援的 at-rule 加入增強層。偵測只決定是否啟用可選樣式，不能取代運行時狀態和無障礙檢查；prefers-reduced-motion 始終優先。舊瀏覽器得到穩定的無動畫路徑，支援者得到過渡增強。通過真實瀏覽器矩陣、視覺回歸、鍵盤操作和首屏指標驗證後，再逐步擴大範圍。」
分步驟深入解答
1. 定義基礎體驗
預設層必須包含完整佈局、焦點樣式、錯誤回饋和可操作狀態，不依賴動畫結束事件。元件卸載、路由跳轉或網路失敗時，內容仍能直接到達目標狀態。
2. 分離能力查詢與狀態選擇
把 at-rule 支援判斷放在 CSS 能力層，把「是否打開面板」「是否正在離場」等狀態放在類名或屬性層。能力查詢回答瀏覽器是否能解析規則，狀態選擇回答元件現在應顯示什麼，二者不能混為一個瀏覽器分支。
3. 組織層疊與回退
先載入基礎規則，再在 @supports 條件內增加增強規則。增強規則只覆蓋必要屬性；解析失敗時，未知區塊應被忽略而不破壞基礎樣式。避免依賴增強層重置基礎層的關鍵尺寸或顏色。
4. 處理動效偏好
在增強層內繼續遵守 prefers-reduced-motion: reduce，將過渡縮短或關閉，並確保焦點、關閉和錯誤狀態仍有明確回饋。不能用「支援 view transition」繞過使用者偏好。
5. 覆蓋 SSR 與 WebView
首屏 HTML 不應等待客戶端偵測；伺服器端輸出基礎結構，客戶端只負責可選增強。測試嵌入 WebView、舊瀏覽器、部分支援和停用動畫的環境，確認未知 at-rule 不會產生白屏或佈局跳動。
6. 驗證與發布
建立瀏覽器與功能矩陣，做視覺回歸、鍵盤/螢幕閱讀器測試、CLS/LCP 對比和錯誤日誌採樣。先對一個元件或低風險頁面灰度；若回歸或投訴上升，移除增強層開關即可恢復基礎體驗。
高品質示範回答
我會先實現不依賴新語法的基礎佈局、狀態和無障礙，再用 @supports 的 at-rule 能力查詢增加可選動畫。能力查詢只判斷解析能力，元件狀態仍由類名或屬性控制；prefers-reduced-motion 優先級更高。SSR 直接輸出基礎 HTML，增強層失敗時被忽略。發布前覆蓋舊瀏覽器、WebView、SSR、鍵盤和視覺回歸，觀察 CLS/LCP 與錯誤回饋；先灰度單個元件，異常時關閉增強開關而不回滾基礎路徑。
常見錯誤
- 按瀏覽器名稱分支 → UA 漂移和誤判 → 按能力查詢。
- 把解析支援當作行為完整 → 部分實作仍有差異 → 做真實瀏覽器矩陣與回歸。
- 增強層覆蓋基礎尺寸 → 不支援時佈局破壞 → 增強規則只覆蓋可選屬性。
- 忽略減少動效偏好 → 使用者體驗受損 → 在增強層再次處理媒體查詢。
- 讓首屏等待客戶端偵測 → 白屏或佈局跳動 → SSR 先輸出基礎體驗。
追問及應對
@supports 回傳支援就能放心使用嗎？
不能。它只說明解析器接受條件，需要在目標瀏覽器驗證具體 at-rule、事件時序和降級路徑。
為什麼不直接刪除舊 CSS？
新能力可能在 WebView、企業瀏覽器或輔助技術環境中缺失。基礎層是可靠的長期契約，增強層應可獨立撤銷。
如何測試減少動效？
在自動化和人工測試中啟用 prefers-reduced-motion: reduce，確認動畫縮短或取消後，焦點、狀態和關閉操作仍清晰可見。
何時可以把增強設為預設？
當目標環境覆蓋、視覺與無障礙回歸、效能指標和錯誤率達到門檻，並且仍保留基礎回退時，才可擴大預設範圍。