[css-contain][css-anchor-position-1] Should size/layout containment also contain anchor names?

[vmpstr]

In #9100 we resolved that style containment should contain anchor names.

The containment spec, non-normatively says the following about the size containment:

When paired with layout containment, though, possible optimizations that can be enabled include (but are not limited to):

• When the style or contents of a descendant of the containment box is changed, calculating what part of the DOM tree is "dirtied" and might need to be re-laid out can stop at the containment box.
• When laying out the page, if the containment box is off-screen or obscured, the layout of its contents (i.e. "laying out in-place") can be delayed or done at a lower priority.

I don't believe these optimizations would hold if anchor names are not contained by size or layout containment.

I was thinking about this in context of content-visibility, which would need to contain anchor names in some way, but it also sets style containment so #9100 should be enough to satisfy that concern.

[tabatkins]

Layout containment seems like an obvious yes - if we didn't have it contain anchor names, it would defeat the optimizations that layout containment is meant to enable. This is similar to how layout containment prevents you from seeing baselines inside the content.

Size containment seems like an obvious no - size containment just breaks parent/child layout cycles, but doesn't let us actually skip any meaningful work in the general case. Note that size containment specifically calls out baseline alignment as something it does not stop.

So I suggest we add layout containment to the list of things that scope anchor names, but do not add size containment.

[css-meeting-bot]

The CSS Working Group just discussed [css-contain][css-anchor-position-1] Should size/layout containment also contain anchor names?, and agreed to the following:

• RESOLVED: Layout containment contains anchor names and size containment/paint containment do not

The full IRC log of that discussion

<keithamus> TabAtkins: already in spec that style containment triggers containment of anchor names
<keithamus> TabAtkins: should other containments have this? Layout containment should for the same reason that it censors baselines. If it didn't you'd have to do layout in the subtree.
<keithamus> TabAtkins: defeats point of containment
<keithamus> TabAtkins: size containment should depend on children size and layout children etc. No guarantees are made about being able to defer work on layout containment
<keithamus> TabAtkins: size containment should not scope anchor names
<emilio> q+
<keithamus> TabAtkins: we use size containment as a cycle breaker a lot.
<miriam> q+
<keithamus> TabAtkins: scoping it means you wouldnt be able to use container queries and anchor names on the same page.
<keithamus> TabAtkins: paint containment doesn't for the same reason
<astearns> ack emilio
<keithamus> emilio: I guess scoping would work both inside and outside right?
<keithamus> TabAtkins: no
<keithamus> emilio: so some kind of named scoping? I don't see how they change the constraints?
<keithamus> emilio: if a name bleeds inside a layout contained thing...
<keithamus> emilio: does layout containment also scope counter names and so on?
<keithamus> TabAtkins: no and it shouldn't. You dont need to do layout for counter names, just box tree.
<keithamus> emilio: I was just confused about what point and where in the dependency tree
<astearns> ack miriam
<keithamus> miriam: container queries add layout containment as well. Even if we restrict on layout containment we still have problems on how these two interact.
<keithamus> miriam: you cant use anchoring across different containers
<keithamus> futhark: you can't anchor something inside the size container outside, or vice versa
<keithamus> TabAtkins: regardless if we allowed names to leak out of layout containment it defeats the point of layout containment.
<keithamus> TabAtkins: I think it's still a requirement that layout containment scopes the values
<keithamus> miriam: should we open a new issue to resolve how these two interact?
<keithamus> astearns: a developer need to use these across boundaries trumps the need for good optimisations
<keithamus> chrishtr: resolve this then raise new issue?
<keithamus> astearns: yes resolve this issue and then work out how it interacts, revisit it if it turns out there's a need to anchor across boundaries
<keithamus> astearns: did futhark's remarks change your position TabAtkins?
<keithamus> TabAtkins: same. It only matters for style queries
<keithamus> futhark: no it's also generated compute from... layout on outside
<keithamus> TabAtkins: that's not in the spec right now as far as I can tell
<keithamus> futhark: yes, container type size also applies layout, size, containment
<keithamus> futhark: this is not a problem specific to layout containment, also style containment...
<keithamus> TabAtkins: okay. Let's discuss that in the new issue
<keithamus> PROPOSED RESOLUTION: Layout containment contains anchor names
<keithamus> PROPOSED RESOLUTION: Layout containment contains anchor names and size containment/paint containment do not
<keithamus> RESOLVED: Layout containment contains anchor names and size containment/paint containment do not
<keithamus> TabAtkins: I have an anchor breakout session in the w3 breakout sessions to resolve the remaining issues. Provisional time slot for now.
<keithamus> astearns: we can use that session for a wider audience hopefully
<keithamus> fantasai: those breakouts are for across w3. So we want to resolve issues on our own, but discuss stuff with the broader community in the breakout
<keithamus> TabAtkins: I thought it was the same as TPAC wednesday.
<keithamus> astearns: we'll figure out some extra meeting times.