我的知識庫

主張 vs 可佐證，與延伸資源

閱讀時間約 10 分鐘

這一篇把整個專欄的說法按證據強度分級，並標明哪些是穩定標準、哪些是瀏覽器相依的行為、哪些是 hack、哪些是設計主張。實作時的判斷原則：A 級可以直接依賴；B 級要驗證目標瀏覽器矩陣；C 級要寫註解說明為什麼用它、何時要重測；D 級是取捨，不是對錯。

A 級：穩定標準，可直接依賴

說法依據
prefers-color-scheme 值只有 light / dark，無偏好回報為 lightMDN；Baseline widely available，2020-01
color-scheme 影響畫布底色、捲軸、表單控件、UA 提供的 UIMDN；Baseline widely available，2022-01
color-scheme 是可繼承屬性，可局部覆寫MDN／CSS Color Adjustment
only light 禁止 UA 覆寫色彩配置MDN；Chrome Auto Dark Theme 文件列為退出方式
<meta name="color-scheme" content="only dark"> 是無效值MDN
meta 應放在任何 CSS 之前以避免載入閃爍MDN 明文建議
light-dark() 需要 color-scheme 有值才會回傳第二個參數MDN
WCAG 2.2 SC 1.4.3 AA：一般文字 4.5:1、大字 3:1（18pt／14pt 粗體 ≈ 24px／18.5px），logo 文字無對比要求W3C Understanding SC 1.4.3
WCAG SC 1.4.11：介面元件與必要圖形 3:1W3C
Android WebView 依 app 佈景的 isLightTheme 決定 prefers-color-schemeAndroid 官方文件
setForceDark() 對 targetSdk ≥ 33 是 no-opAndroid 官方文件／behavior changes 13
algorithmic darkening 只在「內容未用 prefers-color-scheme」等條件同時成立時發生Android 官方文件
WebView 走 UA 反色路徑時 prefers-color-scheme: dark 求值為 falseAndroid 官方文件
WebKit 預設不會自動把網頁內容變暗WebKit 行為，多方一致
forced-colors: active 下 UA 以系統色關鍵字提供色盤MDN
forced-color-adjust 只應用於支援使用者的顏色／對比需求MDN 明文

B 級：瀏覽器相依，需驗證目標矩陣

說法現況與注意事項
light-dark() 可用Baseline newly available，2024-05；依 30 個月規則約 2026-11 才進入 widely available。長尾瀏覽器仍需 fallback 或建構期降級
light-dark() 的影像值支援度落後於顏色值，必須用 @supports 保護
theme-color 的 media 屬性Safari 15 起支援（macOS／iOS）；桌面 Chrome 自 v93 起僅對已安裝 PWA 生效；Android 各瀏覽器支援零散。多個 tag 時採用第一個匹配者
Sec-CH-Prefers-Color-SchemeChromium 93+；高熵提示需 Accept-CH opt in；第一個請求拿不到；Safari／Firefox 不支援。定位是優化而非解法
scrollbar-color / scrollbar-width標準且廣泛支援，但 macOS 覆蓋式捲軸的版面影響、以及動畫的效能問題需實測
SVG favicon 的媒體查詢各瀏覽器對分頁列背景的判定不一致，不應依賴
oklch() 相對顏色語法（from）比 oklch() 本身更新，生產環境建議建構期降級
Chrome Auto Dark Theme 的實際演算法未公開細節，且會隨版本調整；模擬與實機可能不同

C 級：Hack，需註記與定期重測

做法風險
input:-webkit-autofill 用 box-shadow inset 覆蓋背景、transition: 5000s 拖延依賴 UA 樣式的實作細節，Chromium 改版可能失效。優先靠 color-scheme 解決
filter: brightness()/saturate() 調暗照片對使用者上傳內容不安全；對需要真實色彩的內容會造成錯誤
filter: invert() 反轉圖示只在單色圖示上勉強可用；currentColor 或 CSS mask 才是正解
UA 字串辨識 in-app browser（FBAN／Instagram／Line/）只可用於記錄與除錯，不可用於分支主題邏輯
body { visibility: hidden } 直到 JS 就緒把閃爍換成白畫面延遲，惡化 FCP／LCP，JS 失敗時整頁不可見。不建議

D 級：設計主張，有理由但非定論

「不要用純黑背景」 — 機制解釋（光暈、缺乏下探空間）成立，Material 也把基準表面訂在 #121212 而非純黑，但「一定不能用 #000」不是硬性規則。OLED 真黑省電、部分品牌刻意採用純黑，都是合理選擇。

「暗色主題應避免飽和色」 — Material 明確如此建議，理由是視覺震盪與對比不足。這是設計指引，不是規範；能通過對比檢查的飽和色仍可使用。

「三態切換器 vs 兩態開關」 — 這是專欄內部就存在的衝突：Google 的 modern-web-guidance 建議不要暴露三個狀態，理由是視覺回饋容易混淆；而三態的價值在於「跟隨系統」可回復。本專欄的立場是內容型網站用兩態、工具型產品用三態或在設定頁提供三態，但這是取捨判斷，不是有證據支持的最佳解。

「暗色模式省電」 — 只在 OLED／AMOLED 面板、且畫面大面積為深色時顯著，LCD 幾乎無差別，且與亮度強相關。當附帶好處合理，當主要賣點會誇大。

「亮底暗字的閱讀表現優於暗底亮字」 — 視覺心理學上 positive polarity 優勢有相當文獻支持（機制為瞳孔收縮、景深增加），且散光使用者在暗底亮字下更易感到模糊。本專欄未逐一查證原始論文，此處標為 D 級。同時，畏光、偏頭痛與部分低視力使用者在暗色下更舒適也是真實需求。結論仍是：雙主題的價值在於讓使用者選，不在於哪一套比較好。

「暗色主題正文字重要加一階」 — 光暈導致細字在深底上看起來更細，這個現象可觀察；但具體要加多少、要不要關掉 -webkit-font-smoothing: antialiased，需要在目標字型與螢幕上實際比對，沒有通用答案。

未查證與待追蹤

  • Facebook／Instagram／LINE／X 等 app 內建瀏覽器的具體版本行為未逐一實測。本專欄的相關敘述是從 Android WebView 與 WKWebView 的官方機制推導而來，而非逐 app 驗證。實務上唯一可靠的做法是用診斷頁自己跑一次，見 In-app WebView 專篇。
  • 桌面 Chrome 對 theme-color media 屬性的支援是否已擴大到一般分頁（引用來源為 2021 年前後的資料，可能已變動）。
  • light-dark() 進入 Baseline widely available 的實際時點，以及屆時是否還需要建構期降級。
  • 部分 in-app browser 的儲存持久性：哪些 app 使用非持久化資料存放區、行為是否隨版本改變。
  • View Transitions 用於主題切換的效能特性，尤其在低階 Android 裝置上。

延伸資源

規範與參考文件

平台官方

指引與實務

與站內其他筆記的關係

  • Design Pattern 高級詳解：三層 token 架構本質上是「間接層」模式在設計系統上的應用——語意層隔離了原始值與使用端，讓主題成為可替換的實作。
  • AI Agentic SaaS：其中的 UIUX 章節與本專欄的 token 設計互為前後，前者談介面架構、本專欄談顏色系統的落地。
  • 小商務・落地客製化網站服務：交付給客戶的落地頁大量透過社群連結被開啟，In-app WebView 專篇 的檢查清單可以直接放進交付驗收項目。

反向連結