[css-contain-2][css-conditional-5] Weaker form of layout containment for container queries.

[bfgeek]

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.

• Can't baseline align.
• Can't allow abspos/fixedpos elements to escape. https://github.com/w3c/csswg-drafts/issues/10102
• Can't allow scrollable overflow of children to contribute.
• Forces a stacking context (but this likely is "fine").

And we are breaking the layout containment optimization via allowing anchors to escape layout contained subtree, e.g. https://github.com/w3c/csswg-drafts/issues/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 https://github.com/w3c/csswg-drafts/issues/10040 and make layout containment contain anchors again.

[mirisuzanne]

I also would love to make this distinction, and prefer option 2. It seems like something we would have to do with some urgency to avoid compat issues?

[bfgeek]

Yeah it's somewhat urgent to make this change - I'll Adgenda+ think to gauge the temperature on this.

[css-meeting-bot]

The CSS Working Group just discussed Containment, and agreed to the following:

• RESOLVED: container-type does not force layout containment, but does force an independent formatting context

The full IRC log of that discussion

<fantasai> Topic: Containment
<fantasai> github: https://wiki.csswg.org/planning/tpac-2024#proposed-covid-protocols
<fantasai> iank_: When we did CQ, we split containment into layout and size containment
<fantasai> iank_: inline-size and block-size also
<dbaron> github: https://github.com/w3c/csswg-drafts/issues/10544
<fantasai> iank_: We've been running into issues because of enforcing layout containment
<florian> q+
<fantasai> iank_: when you CQ, you can't baseline-align, you can't allow abspos/fixedbpos to escape, scrollable overflow is broken, etc.
<fantasai> iank_: side-effects are annoying for developers
<fantasai> iank_: After investigation, the only restriction we really need is that it establishes a new formatting context
<fantasai> iank_: Lots of issues where devs ask us to remove these restrictions
<fantasai> iank_: a few paths forward
<emilio> q+
<fantasai> iank_: most ideal one, which contains the most compat risk -- but we're fine trying that, roll out behind a flag and work with devs to fix sites -- is to change container type to not enforce layout conainment, just size containment
<fantasai> iank_: and also establish a new formatting context
<fantasai> iank_: that's my ideal proposal
<fantasai> iank_: There are a couple other variants possible
<fantasai> iank_: miriam would also like to take this variant
<Rossen2> ack florian
<fantasai> florian: I'm unsure. I understand the desire to relax these constraints
<fantasai> florian: but not convinced about necessity
<fantasai> florian: e.g. abspos, if you allow to escape, then at a higher level in the tree they could cause scrollbars
<fantasai> florian: which then change the layout space you have to lay out in
<fantasai> florian: which changes the width you're querying against
<fantasai> florian: so it's annoying, but the constraint was there to break the circularity
<fantasai> florian: so yes, annoying, but are they necessary? and otherwise how do you cope?
<fantasai> iank_: falls under "always move forward" constraint
<fantasai> iank_: if you set up container, then can cause relayout
<fantasai> iank_: principle is moving forward -- so you add scrollbars, and don't remove them
<Rossen2> ack emilio
<fantasai> emilio: was going to bring up similar concerns
<fantasai> emilio: last time I checked, browsers still somewhat inconsistent wrt circularities
<fantasai> emilio: has that changed?
<fantasai> emilio: not opposed to removing, but...
<fantasai> emilio: for all browsers it's straighforward to do *something*
<fantasai> emilio: we break cycles similarly to webkit
<fantasai> iank_: I don't think you or webkit are following the spec
<fantasai> emilio: for us it would be a bigger change, because circular case would become a lot more common
<fantasai> iank_: block-size circularity is pretty common, actually
<fantasai> iank_: and I would like to fix this for web developers. It's the #1 complaint we receive for container queries
<florian> q?
<fantasai> emilio: they should complain to the WG
<florian> q+
<fantasai> iank_: they have been
<Rossen2> ack florian
<fantasai> florian: "always move forward" approach, you're saying FF and WK don't follow it well? How well is specified?
<fantasai> florian: Are we sure that we can gain interop on this approach?
<fantasai> florian: if so, then that's a path forward
<fantasai> florian: but if unproven, then maybe it's premature to resolve this issue
<fantasai> florian: maybe need to make sure "always move forward" is web-compatible
<fantasai> iank_: We do it today, so definitely web-compatible
<fantasai> iank_: FF and WK fail some tests because not doing it correctly
<fantasai> iank_: it comes down to interleaving style and layout, and I think we're the only ones doing it correctly today
<fantasai> florian: is it well-defined enough?
<fantasai> iank_: I also don't want to stall on this issue, because compat closes
<emilio> +1
<Rossen2> ack fantasai
<fantasai> fantasai: Can't speak for webkit officially because haven't discussed internally
<emilio> fantasai: can't speak for webkit, but in principle we want to support authors making their use cases work
<emilio> ah
<fantasai> fantasai: Some concerns about style/layout interleaving being underspecified -- I know Tab was handwaving at it in anchorpos spec
<fantasai> fantasai: would be good to get that specced thorougly
<fantasai> fantasai: but I think we should support Chrome experimenting to see how far we can push this in the direction that authors expect
<fantasai> iank_: [proposal]
<fantasai> iank_: Option 1 is introducing a new containment type, and then we have to define what that does
<fantasai> iank_: This option bypasses it
<iank_> proposed resolution: container-type does not force layout containment, but does force an independent formatting context.
<florian> i/[proposal]/florian: Not exactly sure what the difference in practice is between option 1 and 2, but seems fine.
<fantasai> RESOLVED: container-type does not force layout containment, but does force an independent formatting context
<Rossen2> fantasai: asking TabAtkins and iank_ to work on this independently and bring it back to the WG for review
<TabAtkins> Yeah happy to get an edit into the spec and ask for review
<fantasai> s/this independently/defining style+layout interleaving more thoroughly/