[css-contain-3][css-anchor-position-1] Containment makes it difficult to use anchor positioning with container queries

[mirisuzanne]

Currently, container queries rely on several types of containment: size, layout, and style. This already causes some confusion with authors, when fixed-position elements nested in a container are now fixed to the container rather than the viewport (thanks to layout containment).

That issue will become much more noticeable when container queries interact with anchor positioning. As currently defined, layout and style containment will make it impossible for elements to anchor across different containers. I think that will mean:

• Positioned elements outside a container cannot see anchors inside a container, since style containment scopes the anchor name.
• Positioned elements inside a container cannot use an anchor outside the container, since layout containment doesn't allow reference to external layout? (I'm less clear on the interaction here)

While these decisions all make sense in terms of 'the promise' that each containment makes, it will cause a lot of problems for users who want to use both container queries and anchor positioning. Authors should be able to use these features without one constantly interfering with the other.

Since container queries are somewhat abstracted away from containment (we set a container-type, and browsers apply containment as-needed), I think the only path forward here is defining more subtle and targeted containment rules for container queries. Are there ways that we can relax how much layout and style containment is required to make container size queries work?

(This came out of discussion on #9349)

/cc @tabatkins

[lilles]

Currently, container queries rely on several types of containment: size, layout, and style. This already causes some confusion with authors, when fixed-position elements nested in a container are now fixed to the container rather than the viewport (thanks to layout containment).

That issue will become much more noticeable when container queries interact with anchor positioning. As currently defined, layout and style containment will make it impossible for elements to anchor across different containers. I think that will mean:

• Positioned elements outside a container cannot see anchors inside a container, since style containment scopes the anchor name.

Right, it can only see the anchor-name of the container itself given the current spec for anchor-name:

"Anchor names are style-contained, scoped to a sub-tree."

• Positioned elements inside a container cannot use an anchor outside the container, since layout containment doesn't allow reference to external layout? (I'm less clear on the interaction here)

Even style containment does that here:

https://drafts.csswg.org/css-contain-2/#property-scoped-to-a-sub-tree

While these decisions all make sense in terms of 'the promise' that each containment makes, it will cause a lot of problems for users who want to use both container queries and anchor positioning. Authors should be able to use these features without one constantly interfering with the other.

Since container queries are somewhat abstracted away from containment (we set a container-type, and browsers apply containment as-needed), I think the only path forward here is defining more subtle and targeted containment rules for container queries. Are there ways that we can relax how much layout and style containment is required to make container size queries work?

The reason why we added style containment for size containers was that generated content for counters and quotes inside the container could affect layout outside the container through intrinsic sizing, which again could affect the size of the size container, which would cause circularities in the layout when counter/quotes styles depended on size query evaluation.

Counters and quotes need to be style contained for size containers.

[mirisuzanne]

@lilles Right, so the questions are:

• Would it be possible to have container-type: inline-size apply those containments (counters and quotes) without applying other aspects of style containment?
• And, if so, can we do something similar to apply a subset of layout containment as well? Something that would keep container queries stable, but not interfere with anchor positioning?

[vmpstr]

There is a similar desire for timeline names not being contained by style containment: #8915 (comment)

The difference is that being able to discover an anchor name likely has more implications in needing more layout (is that true?). In any case, it seems that maybe having style contain names vs contain counters are two separate needs that could be addressed by two different values.

FWIW, for content-visibility, we do want to contain names as well as counters, so that part is still necessary

[lilles]

@lilles Right, so the questions are:

• Would it be possible to have container-type: inline-size apply those containments (counters and quotes) without applying other aspects of style containment?

Sure. I don't know if it makes sense to introduce separate contain keywords or just do it implicitly through container-type.

• And, if so, can we do something similar to apply a subset of layout containment as well? Something that would keep container queries stable, but not interfere with anchor positioning?

I didn't immediately spot any items that could be lifted https://drafts.csswg.org/css-contain-2/#containment-layout but @bfgeek should have a look, but this was specifically about anchor-name containment that's not yet in the list, right?

[mirisuzanne]

this was specifically about anchor-name containment that's not yet in the list, right?

My instinct would be to start with the implicit change to container-type behavior, and only add a keyword if we find it would be useful later. But we could discuss.

I don't know if it makes sense to introduce separate contain keywords or just do it implicitly through container-type.

Yeah… or anything else related to positioning that might interfere with anchorPos being used across container boundaries. I'm not sure that I know exactly what might impact that.

[chrishtr]

I agree that it's important to support anchors across container query boundaries, and also across every other kind of layout boundary such as content-visibility, for onscreen content. In addition, I don't think there is a big performance problem with excluding anchor-name from style and layout containment, except as it relates to skipped content-visibility:auto subtrees.

So what I propose is the following:

• Exclude anchor-name from style and layout containment (reverting the resolution in [css-contain][css-anchor-position-1] Should size/layout containment also contain anchor names? #9349 last week)
• Specify that anchor-name cannot cross skipped content-visibility: auto subtree boundaries

Agenda+ with that proposed resolution.

[chrishtr]

Agenda+ with that proposed resolution.

Small amendment via a third bullet:

• if the anchor is on-screen, then the anchored element is considered relevant to the user

[vmpstr]

For posterity, also reverts resolution in #9100

[css-meeting-bot]

The CSS Working Group just discussed [css-contain-3][css-anchor-position-1] Containment makes it difficult to use anchor positioning with container queries, and agreed to the following:

• RESOLVED: Undo the previous resolution - anchor names are not blocked by any form of containment. But they *are* blocked from escaping a "skipped content" element.
• RESOLVED: And if a positioned element is "relevant to the user", any element it's anchoring to remains "relevant to the user" as well.

The full IRC log of that discussion

<chrishtr> miriam: right now CQ relies on on side effects from anchor positioning, because anchor names are contained by style containment
<chrishtr> miriam: this will also likely cause a problem for other areas such as names for scroll-driven animations
<chrishtr> miriam: developers will be frustrated if one stops the other from working
<TabAtkins> chrishtr: Proposed resolution (from the issue) is undo the previous resolution, and have anchor-names no longer be contained by style or layout or size
<TabAtkins> chrishtr: So that anchor positioning and CQs can work well together
<TabAtkins> chrishtr: However, we still need skipped subtrees (from c-v: auto) to block those anchor names
<vmpstr> auto or hidden, presumably
<TabAtkins> chrishtr: Because when such content is offscreen and skipped, we want the UA to be able to skip rendering entirely, which rquires not doing the layout necessary to position the anchor
<TabAtkins> chrishtr: That's fine because the content is offscreen anyway, so anchoring to is isn't useful.
<miriam> q+
<Rossen_> ack miriam
<chrishtr> miriam: wonder if layout containment is also an issue
<kizu> q+
<emilio> q+
<TabAtkins> chrishtr: My proposed res also has it escape layout containment, which I think addresses your concern
<Rossen_> ack kizu
<TabAtkins> kizu: Some of the cases we'll be fixed by popover in the top layer, it'll escape containment
<TabAtkins> kizu: But I think escaping via fixpos escape
<TabAtkins> TabAtkins: It's just that anchor names escape, not the positioned element
<TabAtkins> kizu: Okay, I thought there were other cases talked about in the thread, but if it's just anchor names that's okay
<TabAtkins> chrishtr: Right
<TabAtkins> miriam: But my issue is if an element inside a container is able to position relative to an element outside the container; that violates layout containment of the container for the abspos
<Rossen_> q?
<TabAtkins> chrishtr: Yes, it would be contained.
<TabAtkins> emilio: I misunderstood Chris about whether this affects layout containment
<TabAtkins> emilio: I'm confused - would the anchoring work?
<TabAtkins> emilio: wouldn't this mean you can't anchor anything outside your CB chain, right?
<TabAtkins> emilio: And if you hit a fixpos CB that prevents you from going further up, right?
<Rossen_> ack emilio
<TabAtkins> chrishtr: The case we're addressing is an element outside the CQ beinga ble to anchor to something inside the CQ
<TabAtkins> iank_: Right, it's not an OOF inside the subtree beigna ble to escape, it's about being able to anchor to something inside the container
<TabAtkins> emilio: Okay, yeah, I was talkinga bout the ohter way, with the positioned element inside the container
<miriam> q+
<kizu> q+
<TabAtkins> TabAtkins: Remember that top layer pulls it out of the tree, and you can move it further up.
<TabAtkins> q+
<khush> q+
<Rossen_> ack miriam
<TabAtkins> miriam: I don't think youc an always move it futher up the tree. I want to see if we can solve that half of the problem,t oo.
<TabAtkins> miriam: Containers created a fixpos CB is, as far as I can see, always a footgun, it's not something people want from containers.
<TabAtkins> miriam: So if we can remove that limitation from CQs that would be excellent
<TabAtkins> kizu: For the second part, an element inside a container and you want to position it outside without the top layer, the only thing I can think of is position-container, which lets you position to a different block
<Rossen_> ack kizu
<Rossen_> ack TabAtkins
<chrishtr> TabAtkins: position container can't be used, because it uses the same scoping as anchor names
<chrishtr> TabAtkins: for the same reasons that the restrictions are applied in the first place
<chrishtr> TabAtkins: and changing that would amount to the same thing as pulling something up in the tree, which is a separate feature possibility
<chrishtr> TabAtkins: the top layer is the best solution for all this
<chrishtr> TabAtkinss: if we want some other more general thing we can solve it in the position spec
<chrishtr> TabAtkins: propose we not try to solve that problem here
<Rossen_> ack khush
<chrishtr> khush: responding to comment about anchor being on screen causing the anchored element being relevant to the user
<chrishtr> khush: not sure how to implement that
<chrishtr> vmpstr: if on screen and scrolled offscreen, wont' stop being relevant
<chrishtr> TabAtkins: there'd be a hysteresis
<chrishtr> khushal: right, would need to bring an offscreen thing back to the screen for it to take effefct
<vmpstr> q+
<Rossen_> ack vmpstr
<chrishtr> vmpstr: minor clarification. Chris mentioned c-v: auto, but shouldn't we include hidden?>
<chrishtr> chrishtr: agreed
<chrishtr> chrishtr: hidden should be skipped
<chrishtr> TabAtkins: this falls out of the definition of skipped
<TabAtkins> <TabAtkins> chrishtr: Proposed resolution (from the issue) is undo the previous resolution, and have anchor-names no longer be contained by style or layout or size
<TabAtkins> 08:08 <TabAtkins> chrishtr: So that anchor positioning and CQs can work well together
<TabAtkins> 08:08 <TabAtkins> chrishtr: However, we still need skipped subtrees (from c-v: auto) to block those anchor names
<TabAtkins> chrishtr: A little more precisely, a positioned element can anchor to something in a contained subtree, but not the opposite
<TabAtkins> TabAtkins: That's handled by just saying the anchor names arent' contained
<TabAtkins> RESOLVED: Undo the previous resolution - anchor names are not blocked by any form of containment. But they *are* blocked from escaping a "skipped content" element.
<TabAtkins> RESOLVED: And if a positioned element is "relevant to the user", any element it's anchoring to remains "relevant to the user" as well.
<Rossen_> github-bot topic: https://github.com//issues/9149

[vmpstr]

The second resolution isn't what I was thinking about initially. I think it's a good one, but there are a couple of cases:

1. Anchored element (A) and positioned element (P) are both relevant to the user, then
   a. A's container with c-v auto is scrolled offscreen -- it should still remain relevant
   b. P's container with c-v auto is scrolled offscreen -- it should still remain relevant
   c. Both A's and P's containers are scrolled off screen -- not sure if things should stay relevant?
2. A is not relevant to the user, so its anchor-name should not be discoverable
3. P is not relevant to the user -- I don't think it should become relevant, since then we'd need to know it's being positioned

I propose spending a few minutes thinking through all of the cases here, since I want to avoid to accidentally requiring rendering in an otherwise skipped subtree

[vmpstr]

After a bunch of discussions, I think it's fine if positioned elements are within c-v, because there's paint containment that would end up clipping it if if it's moved too far.

It also establishes a containing block, so I don't see a use case for where this anchoring would be expected to work well when the anchor is elsewhere.