[csswg-drafts] [css-align-3][css-position-3] How should safe alignment work for OOF elements when positioned statically? (#11934)

alisonmaher has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-align-3][css-position-3] How should safe alignment work for OOF elements when positioned statically? ==
According to [css-align](https://drafts.csswg.org/css-align/#valdef-overflow-position-safe), when the overflow alignment mode is `safe`, "If the size of the [alignment subject](https://drafts.csswg.org/css-align/#alignment-subject) overflows the [alignment container](https://drafts.csswg.org/css-align/#alignment-container), the alignment subject is instead aligned as if the alignment mode were [start](https://drafts.csswg.org/css-align/#valdef-self-position-start)."

According to [css-position](https://www.w3.org/TR/css-position-3/#staticpos-rect), OOFs are "resolved into a static position by aligning the box into its static-position rectangle, an [alignment container](https://www.w3.org/TR/css-align-3/#alignment-container) derived from the [formatting context](https://www.w3.org/TR/css-display-4/#formatting-context) the box would have participated in if it were [position: static](https://www.w3.org/TR/css-position-3/#propdef-position) (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.

However, [css-align](https://drafts.csswg.org/css-align-3/#auto-safety-position) also notes that for abspos elements, the overflow alignment behavior is based on "the default overflow rect" which is "the bounding rectangle of the [alignment subject’s](https://drafts.csswg.org/css-align-3/#alignment-subject) [inset-modified containing block](https://drafts.csswg.org/css-position-3/#inset-modified-containing-block) and its [original containing block](https://drafts.csswg.org/css-position-3/#original-containing-block)."

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.

According to [css-position](https://www.w3.org/TR/css-position-3/#abspos-layout), an OOFs "[inset-modified containing block](https://www.w3.org/TR/css-position-3/#inset-modified-containing-block) is calculated, defining its [available space](https://www.w3.org/TR/css-sizing-3/#available)."

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](https://www.w3.org/TR/css-position-3/#resolving-insets) 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?

CC @bfgeek @tabatkins @fantasai 

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11934 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 13 March 2025 23:31:37 UTC