[css-contain-2][css-conditional-5] Weaker form of layout containment for container queries. · Issue #10544 · w3c/csswg-drafts (original) (raw)

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.

  1. 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).
  2. 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).
  3. 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.