[csswg-drafts] [css-contain-3] Ancestor Layout Loops with Single-Axis Containment (#6426)

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

== [css-contain-3] Ancestor Layout Loops with Single-Axis Containment ==
In #1031 we identified the need for, and some of the issues with, single-axis containment. Since then Chrome has implemented the basic feature behind a flag – and we've had a chance to explore some of the issues in more depth. We wanted to start a new thread here to provide a collated summary of the issues, and how they relate.

In order for inline-size containment to work, the container has to maintain the same inline-size no matter what happens to the contents inside it – and no matter how much the block-size changes. These are cases where that behavior is difficult to define. We have potential solutions to each individual issue here. But the overarching concern is that all these solutions need to be applied on _arbitrary ancestors of the contained element_, making their impact expensive for browser engines, and unpredictable for authors. 

Hopefully we can attempt some of these solutions in the Chrome prototype, in order to see them in practice.

## Cross-axis overflow and classic scrollbars

Demo: https://codepen.io/miriamsuzanne/pen/yLbNgMx (requires classic scrollbars enabled)

If any ancestor has overflow on the container's block axis, then additional block-size of the contents can trigger a scrollbar on the cross-axis. Classic scrollbars for block-scrolling take up space on the inline-axis, leaving less space for the container.

This is likely to a very common scenario, impacting the majority of sites that uses inline-size containment, since the viewport itself uses auto-scrollbars.

This could be resolved by applying `overflow-gutter: stable` to the nearest ancestor with `overflow: auto` on the container's block axis? However, `overflow-gutter` is currently limited to a single axis (block-scrolling), and might need to handle inline-scrolling as well, in case the scroller has a writing mode orthogonal to the container.

## %-Padding percentages in Orthogonal Writing Modes

Demo: https://codepen.io/miriamsuzanne/pen/PomqWVE

When padding is applied to the block axis in percentages, those values resolve against the inline-size of the parent. By restricting single-axis containment to the inline axis, we eliminate the majority of these issues. However, it's still possible to apply orthogonal writing modes to any arbitrary ancestor with block-padding that would respond to the (now cross-axis) block size of the container.

- This applies to any ancestor with percentage-based block padding orthogonal to the container
- It doesn't matter what elements switch the writing modes, so long as the container & padding are orthogonal

This could be resolved by "zeroing out" any percentage-padding applied to any ancestor on the containers block-axis?

## Auto-sized BFCs effected by floats

Demo: https://codepen.io/miriamsuzanne/pen/mdmJRxW

The auto-sized Block Formatting Context (created by `overflow:hidden`) finds space for itself among various floated elements. However, as the contents expand vertically, the BFC has to contend with additional floated elements, and resizes. Note that:

- The float/s can be "siblings" or even "cousins" of the BFC
- The BFC can be the container, or _any ancestor_ of the container

This could be resolved by adding `clear: both` to all auto-sized ancestor BFCs?

## Aspect ratios (and Orthogonal Writing Modes?)

Demo: https://codepen.io/miriamsuzanne/pen/abWOJYJ

Since aspect-ratio implementations are inconsistent, and may have existing recursion issues (see #6419), I'm not confident that I know what issues here are specific to inline containment. Still it seems like something to keep an eye on - especially when orthogonal writing modes come into play.

This could be resolved in by removing the impact of the preferred aspect ratio? Authors who want to maintain a strict aspect ratio can still do that by applying size containment and defining overflow behavior.

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


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

Received on Tuesday, 6 July 2021 16:27:40 UTC