核心原則

覆寫成本要在開工前報、不能默默承擔。 客製要對抗多層（UA 預設 + 跨瀏覽器 + framework specificity）時、先把「需要寫多少 / 哪幾條 / 是否有殘留風險」攤開、讓使用者用「視覺改善 vs 維護成本」的角度判斷值不值。

為什麼成本要事先告知

商業邏輯

執行者單方決定「這客製值不值得做」會出現兩種失敗：

失敗模式表現
執行者覺得值得、使用者覺得太貴寫了 5 條 CSS 後使用者說「先還原」、白做
執行者覺得不值、使用者覺得很重要沒做、使用者覺得敷衍

兩種失敗都來自「成本與價值的判斷沒對齊」。把成本攤開讓使用者參與判斷、避免兩種失敗。

這次任務的實際情境

觀察

要移除 Pagefind filter 的 <details><summary> disclosure 三角圖示。

我嘗試了：

 1/* 1. UA 預設 marker（Chrome / Firefox） */
 2summary::marker { content: ""; color: transparent; font-size: 0; }
 3/* 2. UA 預設 marker（Safari / 老 Chrome） */
 4summary::-webkit-details-marker { display: none; }
 5/* 3. 改 summary display 避免 list-item 行為 */
 6summary { display: block; list-style: none; }
 7/* 4. 蓋過 pagefind 的 ::after 自訂 chevron */
 8.pagefind-ui__filter-name::after { display: none !important; }
 9/* 5. 處理 reset 邊界外的 fallback */
10/* ... */

寫完後使用者說：「如果要做到這麼大的複寫原設計、先還原回去、先不要做這個變更」。

判讀

我的失敗：開工前沒報「這個客製需要對抗 UA + 跨瀏覽器 + framework 三層、預估 5+ 條 CSS、跨瀏覽器有殘留風險」。直接做、使用者看到改動規模才退回。

正確流程應該在嘗試第 2 條 CSS 時就停下來報告：

移除 disclosure 三角需要對抗：

  • UA 預設 marker（Chrome / Firefox 的 ::marker、Safari / 老 Chrome 的 ::-webkit-details-marker）
  • Summary 預設 display: list-item 行為
  • Pagefind 的自訂 ::after chevron

預估 4-5 條 CSS 跨 3 種瀏覽器寫法、可能有殘留風險（::marker 在某些瀏覽器版本不能用 display: none）。

視覺改善：filter 名稱旁邊少一個小三角。

值得做嗎？

讓使用者判斷再決定。

執行：覆寫成本告知 protocol

開始任何客製前、先評估這三個累積層：

層評估問題
UA 預設跨瀏覽器有差異嗎？需要寫幾種 pseudo？
Framework specificity框架 CSS 用 hash class 提升 specificity 嗎？需要 layers / important / 雙寫嗎？
Framework 渲染週期改了會被 reset 嗎？需要 observer 補打嗎？

任一層有「需要對抗」就把成本報出來、讓使用者參與決定。

內在屬性比較：四種覆寫深度

深度成本適合的視覺改善
1 條 CSS、單一瀏覽器低任何
1-2 條 CSS、跨瀏覽器（用 layers / important）中影響 UX 的視覺改善
3+ 條 CSS、跨瀏覽器 + framework高必要的核心客製
跨 framework 渲染週期、需要 observer 補打最高改善價值極高才值得

「成本 vs 改善價值」的對應 — 高成本只用在高價值場景。

告知時機與格式

觸發點

訊號應該停下來告知
寫到第 2 條 CSS 還沒蓋過原設計是 — 這通常表示有第二、第三層問題
跨瀏覽器寫法（-webkit-、::marker 雙寫）是 — 跨層成本累積
加 !important是 — specificity 戰開始
加 observer 補打防 reset是 — 跟 framework 渲染週期競爭

報告格式

1這個客製需要：
2  - 對抗 [UA / framework / 跨瀏覽器]：N 條 CSS
3  - 殘留風險：[列出可能在某些情境失效的 case]
4  - 改善價值：[視覺差異、UX 改善]
5  
6值得做嗎？或先接受原設計？

讓使用者用「成本 vs 價值」做決定。

設計取捨：客製深度告知的時機

四種做法、各自機會成本不同。這個專案選 A（開工前評估 + 第 2 條 CSS 失敗即告知）當預設、其他做法在特定情境合理。

A：開工前評估三層成本、開工後第 2 條失敗即告知（這個專案的預設）

  • 機制：開工前評估 UA / framework / 渲染週期三層；開工後寫到第 2 條 CSS 還沒蓋過就停下告知
  • 選 A 的理由：使用者參與「值不值」判斷、避免做到一半被退回
  • 適合：所有有覆寫嫌疑的客製
  • 代價：對話成本（一段成本評估 + 等決定）

B：寫到第 N 條才告知（N > 2）

  • 機制：執行者自己加碼、到 4-5 條才停
  • 跟 A 的取捨：B 給執行者更多嘗試空間、A 早提早決；B 在 N 增加時白費時間放大
  • B 是反模式：第 2 次失敗就是 #42 2 次門檻 的訊號、繼續加碼只是放大沉沒成本

C：默默寫到底、不告知

  • 機制：執行者自己承擔、不報告成本
  • 成本特別高的原因：使用者看到改動規模才退回、所有時間白費
  • C 才合理的情境：客製極簡（< 1 條 CSS）、確定不會對抗任何層

D：開工前直接接受原設計、不嘗試

  • 機制：看到客製需求是「對抗多層」就直接拒絕、不寫
  • 跟 A 的取捨：D 完全省成本、A 留空間給「值得做」的客製
  • D 比 A 好的情境：使用者明確說「這是視覺微調」+ 對抗三層、且預估成本高 — 直接接受原設計

判讀徵兆

訊號該觸發告知的時機報告內容
寫到第 2 條 CSS 還沒蓋過原設計立刻列出對抗的層、預估還要寫多少
加跨瀏覽器寫法（pseudo 雙寫）立刻UA 差異、各瀏覽器寫法
加 !important立刻Specificity 戰開始、考慮 layers
加 observer 補打立刻跟 framework 渲染競爭、可能不穩
改善價值不明顯（純視覺微調）開工前列改善內容、讓使用者衡量

核心原則：客製成本是使用者該知道的資訊、不是執行者單方承擔。事先告知 = 共同決定 = 不會做到一半被退回。

成本告知有兩種時機 — 本卡聚焦「實作前告知工程成本」、runtime 持續顯示掃描成本見 #62 Pattern：誠實進度 UX。共同精神是「不 silent 累積負擔」。