- From: Ian Kilpatrick via GitHub <noreply@w3.org>
- Date: Mon, 09 Feb 2026 13:27:36 +0000
- To: public-css-archive@w3.org
bfgeek has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-position-3] Should there be a special fixedpos ICB? == https://drafts.csswg.org/css-position-3/#fixed-positioning-containing-block "The initial fixed containing block is the parent of the initial containing block in the containing block chain." From: https://bugzilla.mozilla.org/show_bug.cgi?id=2014997 https://issues.chromium.org/u/1/issues/482079659 Effectively Blink/WebKit don't have this special fixedpos ICB structure, instead just have a single ICB shared between fixpos & abspos elements. IMO I suspect this language was in the spec so that we could explain how fixedpos element don't move upon scroll, e.g. "boxes do not move when the document is scrolled", and don't contribute to scrollable overflow. However we are going to soon be expanding this capability to attach to the scrollport on all scrollers as part of: https://github.com/w3c/csswg-drafts/issues/12607#issue-3323281455 E.g. the "position-attachment" will explain how fixedpos attach to any scrollers (and we won't be adding 2 nested containing blocks for this purpose). cc/ @dshin-moz IMO We should remove this nested containing-block explanation, and instead explain the side-effects a different way. (and more generally not being able to attach an abspos to a fixedpos at the ICB level seems like a mistake - e.g. the Firefox issue seems like a reasonable things for a web-developer to do). Ian Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13468 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 9 February 2026 13:27:37 UTC