昨天把 csswg-drafts#7807 標成存疑收尾——知道它掛著「Closed Accepted by CSSWG Resolution」又同時掛著「Needs Edits」,但查不到決議內容與日期。今天回頭把這個 issue 的完整討論串、規格現行文字、對應的 WPT 測試,以及三個引擎的即時測試結果全部拉出來對照,結果是一個比「還沒修好」更有意思的狀態:這個 bug 在瀏覽器裡已經修好、修好超過三年,但規格的條文本身從來沒有被編輯過來對齊那個決議。
📖 學
先把決議內容找出來。CSSWG 在 2022 年 11 月 16 日的電話會議上討論了這個 issue,官方紀要(css-meeting-bot 貼的 IRC log)寫著兩個候選方案:一是把「使用」last remembered size 的判斷條件從「是否跳過內容」改成別的;二是把「更新」last remembered size 的判斷條件從「有沒有 size containment」改成「是否跳過內容」。討論裡 Vladimir Levin(vmpstr,Chromium)一開始就偏向第二案,Oriol Brufau(Loirooriol,當時任職 Igalia、同時貢獻 Gecko 與 WPT)沒有強烈意見,主席 Florian Rivoal 附議第二案,最後決議原文是:
RESOLVED: Take second solution for this case. Update the last remembered size if element doesn't skip its contents.
也就是說:last remembered size 該不該被「記錄/更新」,判斷條件要從「元素目前有沒有 size containment」換成「元素目前是不是正在跳過內容」。這兩個條件在最常見的情境(只有 content-visibility: auto,沒有額外疊加 contain: size)下是等價的——跳過內容的唯一原因就是拿到隱含的 size containment。但一旦顯式加上 contain: size,size containment 永遠成立,不管元素有沒有跳過內容,舊條件會讓「記錄」這個動作永久失效,last remembered size 卡死在加上 contain: size之前的那個值——這正是昨天引的 scrollbar jitter 症狀的成因。新條件把「記錄」跟「size containment 存不存在」脫鉤,只看跳過狀態,才能在疊加 contain: size 時繼續正常更新。
接下來查規格文字有沒有照決議改。直接抓 css-sizing-4 的 Editor’s Draft(頁尾標示 Editor’s Draft, 6 September 2026,是查證當下能拿到的最新版本),§5.2.1 Last Remembered Size 的演算法段落原文是:
“At the time that ResizeObserver events are determined and delivered, if an element has a auto keyword in contain-intrinsic-size property, is capable of being a ResizeObserver target, but does not have size containment, record the current inner dimensions of its principal box as its last remembered size.”
這一句用的仍然是舊條件——「does not have size containment」,不是決議裡的「doesn’t skip its contents」。同一頁的 Changelog 只列了一條相關項目,指向另一個相鄰但不同的 issue:「Only used the last remembered size for the auto value of the contain-intrinsic-* properties when the element is skipping its contents to avoid phantom sizes. (Issue 6308)」——這條講的是「使用」last remembered size 的限制(#6308,決議在先、範圍在讀取端),不是 #7807 要求的「記錄」條件修正。換句話說,四年過去,#7807 那個決議從沒被編輯進規格正文,label 上的「Needs Edits」不是走完流程只是還沒排版,而是實實在在地卡了將近四年。
再查有沒有人真的照決議做了。Oriol Brufau 在 2022 年 12 月 30 日於同一個 issue 底下留言補上兩份 WPT 測試:css/css-sizing/contain-intrinsic-size/auto-011.html 與 auto-012.html,兩份的 <link rel="help"> 都直接指向 csswg-drafts#7807。auto-011.html 的 <meta name="assert"> 寫的是「Tests that the last remembered size can be updated when the element has size containment but doesn’t skip its contents」——一字不差對應決議文字;它的測試案例名稱就叫「contain:size does not prevent recording last remembered size」。auto-012.html 更進一步重現原始 bug 報告裡的完整場景:先正常量測、再加 contain: size(此時該用 contain-intrinsic-size 的 fallback 值)、捲出畫面(此時該切到 last remembered size)、再捲回來、再改 fallback 值——七個階段依序斷言尺寸,確保不會有昨天那種「捲出去退回舊值、捲回來又跳回新值」的反覆跳動。
最後查三個引擎現在跑起來是什麼結果。wpt.fyi 的 stable、aligned 頻道最新一批結果(revision 27f97e5079,產生於 2026-09-29)裡,Chrome 154.0.8037.57(linux)、Firefox 156.0.1(linux)、Safari 27.0(22625.1.29.11.27,mac)三邊都對這兩份測試回報 auto-011.html 2/2、auto-012.html 7/7 全過。也就是說,拿掉規格文字不談,單看「瀏覽器實際上會不會出現決議要修的那種 scrollbar jitter」,答案是三個引擎在昨天(2026-09-29)的官方 stable 測試批次裡都是乾淨的。這跟昨天那句「WebKit 有獨立的實作迴歸」不是同一件事——bug 277573 講的是 details/summary 元素的展開失敗,跟這裡的尺寸穩定性測試是兩條不同的錯誤路徑,不能互相抵銷或互相佐證。
這裡有一個沒有查到解釋的空隙,必須標記:我找不到任何一手的 Chromium commit 或 crbug 條目明確寫著「這是為了落實 #7807 決議而做的修改」,搜尋只會帶回無關的結果(工程零件、瀏覽器評測站)。我能確認的是「決議存在」「WPT 測試存在且引用該決議」「三引擎在該測試上目前全過」三件事各自成立,但「引擎當初改動的動機與時間點」這條因果鏈缺一手來源,標存疑。
拉回昨天結尾提到的 Interop 2026 名單——19 個 focus areas 裡沒有 containment、也沒有 content-visibility,意思是這個角落不在任何被系統性追蹤、按季量測進度的正式渠道裡。但今天查到的結果證明:沒有 Interop 的正式追蹤,收斂還是可能發生,只是走的是比較舊派的路徑——一次 CSSWG 電話會議決議、一位貢獻者補上引用 issue 編號的 WPT 測試、三個引擎各自在接下來幾年裡把行為改到讓測試通過,沒有儀表板、沒有進度百分比,連規格正文都沒空編輯。這對「規格完成度」與「實作收斂程度」這兩件事給了一個具體反例:它們是兩條可以獨立前進的軸線,而且完全可能其中一條停在原地將近四年,另一條已經走完。對讀規格做合規判斷的人來說,這意味著看到「Needs Edits」標籤時,正文文字本身已經不能當作目前行為的可靠依據——真正該查的是 WPT 測試与 wpt.fyi 的即時結果,而不是 Editor’s Draft 那段還沒被編輯的演算法敘述。
🧠 記
- csswg-drafts#7807 的決議內容與日期,今天查到了:2022-11-16,CSSWG 決議「Update the last remembered size if element doesn’t skip its contents」——把「記錄」last remembered size 的判斷條件從「有沒有 size containment」換成「是否正在跳過內容」,專門解決疊加顯式
contain: size時記錄動作被永久卡死的問題。 - 規格正文四年沒編輯。 直接抓
css-sizing-4Editor’s Draft(標示 2026-09-06)驗證,§5.2.1 的演算法仍寫著舊條件「does not have size containment」,Changelog 只提到旁邊的 #6308(讀取端限制),完全沒提 #7807 對應的編輯。「Needs Edits」這個標籤在這裡是字面意思,不是流程細節。 - 但實作已經收斂:三引擎的 WPT 測試全過。 wpt.fyi stable/aligned 頻道 2026-09-29 的批次(revision
27f97e5079)裡,Chrome 154.0.8037.57、Firefox 156.0.1、Safari 27.0 對auto-011.html(2/2)與auto-012.html(7/7)——兩份直接引用 #7807 且由 Oriol Brufau 於 2022-12-30 提交的測試——全部通過。規格文字沒跟上,但瀏覽器行為已經對齊決議超過三年。 - 規格完成度與實作收斂度是兩條獨立的軸線。 這是今天最值得記住的模型修正:不能用「issue 有沒有 Needs Edits 標籤」或「規格正文寫了什麼」推論瀏覽器現在的行為,唯一可靠的驗證方式是查 WPT 測試本身在做什麼斷言、再查 wpt.fyi 的即時跨引擎結果。
- 這件事發生在 Interop 2026 完全沒追蹤的角落。 昨天提過 Interop 2026 的 19 個 focus areas 不含 containment 與 content-visibility,今天的發現證明「沒有正式追蹤」不等於「不會收斂」,只是收斂得慢、看不到進度儀表板,而且規格編輯這一環可以無限期落後於實作。
- 已標存疑:找不到任何一手 Chromium commit 或 crbug 條目說明三引擎當初是為了落實這個決議才修改行為。 決議存在、WPT 測試引用決議、測試現在全過,這三件事各自查證屬實,但中間的因果鏈(誰、何時、為什麼改)缺一手來源。
✍️ 實踐
- 在自己的專案裡搜尋是否同時使用了
content-visibility: auto、contain-intrinsic-size: auto與顯式的contain: size(或contain: strict)三者疊加的元素——這正是 #7807 的觸發條件。單獨的content-visibility: auto不會踩到這個角落,只有額外顯式加contain: size的元件需要檢查。 - 找到這樣的元素之後,手動重現
auto-012.html的測試步驟:量出正常尺寸 → 加上contain: size→ 捲出視窗 → 捲回視窗 → 改變contain-intrinsic-size的 fallback 值 → 再捲出捲回,確認尺寸每一步都跟預期一致、沒有反覆跳動。三引擎的 WPT 結果顯示這條路徑目前是乾淨的,但自己的元件疊加了其他樣式規則時仍值得手動驗證一次。 - 以後遇到任何 csswg-drafts issue 掛著「Closed Accepted by CSSWG Resolution」但同時掛「Needs Edits」時,別把規格正文當成行為依據——先去 issue 底下找有沒有人補了對應的 WPT 測試(通常會在
<link rel="help">或 issue 留言裡點名檔案路徑),再去 wpt.fyi 查那份測試在 stable、aligned 頻道的即時跨引擎結果,這比讀 Editor’s Draft 準。 - 想追因果鏈的話,下一步可以去查 Chromium 的
git log對LastRememberedSize或ResizeObserver、content-visibility相關檔案的修改紀錄,或是 Gecko 的 bugzilla 搜尋contain-intrinsic-size auto skip,找出三引擎各自的實作 commit 與時間點——這是今天沒查到、仍然空著的那一段。
🔗 延伸學習
content-visibility: autokinda broken by not using last remembered size withcontain: size· csswg-drafts#7807 — 決議原文、兩個候選方案的完整討論串,以及 2022-12-30 補上的 WPT 測試檔名留言。- CSS Box Sizing Module Level 4 — Last Remembered Size — 目前仍卡著舊條件「does not have size containment」的演算法正文,以及只提到 #6308、沒提 #7807 的 Changelog。
- auto-012.html — web-platform-tests — 直接引用 #7807 的七步驟測試原始碼,重現原始 bug 報告的完整場景。
- wpt.fyi — css-sizing contain-intrinsic-size 測試結果 — 可自行查最新一批 stable/aligned 頻道的跨引擎結果,驗證本文引用的 2026-09-29 數字是否還成立。
💬 問 AI
我在查一個 CSS 規格 issue 的「決議已通過但正文沒編輯」的狀態落差,請用你能查到的最新資料驗證,並嚴格區分「你查到的」與「你推論的」。
背景:csswg-drafts#7807 在 2022-11-16 決議「Update the last remembered size if element doesn't skip its contents」,用來修正 content-visibility:auto 搭配顯式 contain:size 時 last remembered size 记录失效、造成 scrollbar 反覆跳動的 bug。css-sizing-4 的 Editor's Draft(我查到的版本標示 2026-09-06)§5.2.1 演算法正文仍寫著舊條件「does not have size containment」,Changelog 只提到相邻的 #6308、没提 #7807。WPT 測試 auto-011.html 與 auto-012.html(2022-12-30 由 Oriol Brufau 提交,rel=help 指向 #7807)在 wpt.fyi 的 stable/aligned 頻道 2026-09-29 批次(revision 27f97e5079)裡,Chrome 154.0.8037.57 / Firefox 156.0.1 / Safari 27.0 全部通過(2/2、7/7)。
請幫我:
1. 查證 css-sizing-4 現在(你查到的當下)的 §5.2.1 正文是否仍是舊條件,還是已經改成「does not skip its contents」——如果已經改了,請告訴我大概的编辑日期或對應的 GitHub PR。
2. 查 Chromium、Gecko、WebKit 三邊有沒有一手的 commit / bugzilla / crbug 記錄可以對應到「為了落實 #7807 決議而修改 last remembered size 的記錄條件」,標明找到的話給連結,找不到就直接說找不到。
3. 用 wpt.fyi 目前最新一批 stable/aligned 結果,重新確認 auto-011.html 與 auto-012.html 在三引擎上是否仍然全過,如果狀態變了(尤其是變差),請指出來。
4. 根據以上,評估「Needs Edits 標籤 + 決議已通過」這種狀態在 csswg-drafts 上是不是常見模式(如果你能查到其他類似案例),還是這是個案。
要求:每一點分開回答,查不到的地方明確寫「查不到」,不要用 SEO 內容站當來源,優先用 W3C / WHATWG / Chromium / WebKit / Mozilla / wpt.fyi 的一手資料。