Layout containment was originally added as a performance optimization for engines. To ensure that a layout inside an element wont affect the layout outside (more or less).
With container queries we split it out into layout+size containment so that we can target one dimension, e.g. layout+inline-size containment. This was good! But IMO it didn't go far enough.
Ideally we should have done weak-layout+inline-size (and there may be still time left to do this).
With container-queries (due to this) we have limited ourselves in a number of ways - e.g.
And we are breaking the layout containment optimization via allowing anchors to escape layout contained subtree, e.g. #10040 with this resolution we've allowed the layout inside of a contain:layout element to affect things outside.
For container queries the only "layout" containment we really need is that it establishes a new formatting context.
(I've quickly checked https://chromium-review.googlesource.com/c/chromium/src/+/5685175 ).
There are a few of potential paths.
- Attempt to change container-queries when used via:
container-type to ensure a new type of "weak-layout" containment (just establishing the new formatting context rule).
- Attempt to change container-queries (via
container-type not to enforce layout containment, (just size containment) and specify that container-type establishes a new formatting context. (In an ideal world my preferred option).
- If not web compatible, (e.g. people might be relying on establishing a containing block for example). We could introduce a new values for
container-type to allow this less strict version. e.g. container-type: new-inline-size
With all 3 of these we should undo - the anchor-pos resolution in #10040 and make layout containment contain anchors again.
Layout containment was originally added as a performance optimization for engines. To ensure that a layout inside an element wont affect the layout outside (more or less).
With container queries we split it out into layout+size containment so that we can target one dimension, e.g. layout+inline-size containment. This was good! But IMO it didn't go far enough.
Ideally we should have done weak-layout+inline-size (and there may be still time left to do this).
With container-queries (due to this) we have limited ourselves in a number of ways - e.g.
And we are breaking the layout containment optimization via allowing anchors to escape layout contained subtree, e.g. #10040 with this resolution we've allowed the layout inside of a contain:layout element to affect things outside.
For container queries the only "layout" containment we really need is that it establishes a new formatting context.
(I've quickly checked https://chromium-review.googlesource.com/c/chromium/src/+/5685175 ).
There are a few of potential paths.
container-typeto ensure a new type of "weak-layout" containment (just establishing the new formatting context rule).container-typenot to enforce layout containment, (just size containment) and specify thatcontainer-typeestablishes a new formatting context. (In an ideal world my preferred option).container-typeto allow this less strict version. e.g.container-type: new-inline-sizeWith all 3 of these we should undo - the anchor-pos resolution in #10040 and make layout containment contain anchors again.