You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-align-3][css-position-3] How should safe alignment work for OOF elements when positioned statically? #11934
According to css-align, when the overflow alignment mode is safe, "If the size of the alignment subject overflows the alignment container, the alignment subject is instead aligned as if the alignment mode were start."
According to css-position, OOFs are "resolved into a static position by aligning the box into its static-position rectangle, an alignment container derived from the formatting context the box would have participated in if it were position: static (independent of its actual containing block)."
Based on these two statements, this would imply that if an OOF is statically positioned, and is aligned with the safe keyword, we'd position it at the start of the alignment container (i.e. the originating parent container) if the OOF overflows that alignment container.
It is not clear to me if this also applies to statically positioned OOFs or not, but if it does, then this would imply that for statically positioned OOFs, we'd look at the default overflow rect when determining safe overflow.
Ignoring this, there is also another issue in assuming that the originating alignment container is used for safe in the case of OOF alignment and overflow, specifically in relation to the OOF available space.
If it is true that when an OOF is statically positioned, and is aligned with the safe keyword, we'd position it at the start of the alignment container (i.e. the originating parent container) if the OOF overflows that alignment container, then this would mean that when the item hits the overflow condition, its IMCB (and its available space) would change to match the definition for 'self-start'.
The problem with this is that it would shift the available space midway through, causing a shift in the layout of the item, which breaks the continuity principle. Is this what we want?
An alternative approach is: if an OOF is statically positioned, and is aligned with the safe keyword, we'd position it at the start of the IMCB if the OOF overflows the IMCB. This would prevent the shift in available space, and would likely still be a reasonable result for authors. It would however mean that it wouldn't match the result of an OOF that was start-aligned, but perhaps that is ok?
@yisibl yeah, I believe this is tied to this issue specifically, and we are both taking different approaches. In blink we are taking the IMCB approach mentioned at the end. It looks like maybe Firefox is using the "static position rectangle". And because removing position: relative changes the IMCB, but not the "static position rectangle", that is why we see this difference in Chromium, which may be a slightly weird side effect of that approach, but it does avoid potential layout shifts.
Activity
Safe alignment in statically positioned OOFs
Safe alignment in statically positioned OOFs
Safe alignment in statically positioned OOFs
Safe alignment in statically positioned OOFs
Bug 1957638 [wpt PR 51741] - Safe alignment in statically positioned …
Bug 1957638 [wpt PR 51741] - Safe alignment in statically positioned …
Bug 1957638 [wpt PR 51741] - Safe alignment in statically positioned …
yisibl commentedon Dec 17, 2025
I've noticed that if the parent element doesn't have
position: relativeset, Blink behaves differently from other browsers. Is this expected?alisonmaher commentedon Jan 5, 2026
@yisibl yeah, I believe this is tied to this issue specifically, and we are both taking different approaches. In blink we are taking the IMCB approach mentioned at the end. It looks like maybe Firefox is using the "static position rectangle". And because removing
position: relativechanges the IMCB, but not the "static position rectangle", that is why we see this difference in Chromium, which may be a slightly weird side effect of that approach, but it does avoid potential layout shifts.Migrate css-flexbox abspos tests to external/wpt
Migrate CSS grid abspos tests to external/wpt
Migrate css-flexbox abspos tests to external/wpt
Migrate CSS grid abspos tests to external/wpt
Migrate css-flexbox abspos tests to external/wpt
Migrate CSS grid abspos tests to external/wpt
Bug 2041261 [wpt PR 60028] - Migrate css-flexbox abspos tests to exte…
Bug 2041265 [wpt PR 60029] - Migrate CSS grid abspos tests to externa…
Bug 2041261 [wpt PR 60028] - Migrate css-flexbox abspos tests to exte…
Bug 2041265 [wpt PR 60029] - Migrate CSS grid abspos tests to externa…
Bug 2041261 [wpt PR 60028] - Migrate css-flexbox abspos tests to exte…
Bug 2041265 [wpt PR 60029] - Migrate CSS grid abspos tests to externa…
Bug 2041261 [wpt PR 60028] - Migrate css-flexbox abspos tests to exte…
Bug 2041265 [wpt PR 60029] - Migrate CSS grid abspos tests to externa…
Bug 2041261 [wpt PR 60028] - Migrate css-flexbox abspos tests to exte…
Bug 2041265 [wpt PR 60029] - Migrate CSS grid abspos tests to externa…