[css-anchor-position] Add containing block rules to acceptable elements in top layer

[jamesnw]

Currently, the spec for Finding an anchor only requires that a positioned el is in a higher top layer than possible anchor for an element in a top layer to be an acceptable anchor.

However, there are also containing block rules for the positioned el, even if it is in a higher top layer. For example, a child element of a popover with position: absolute would have the top layer root element (the popover) as a containing block, and would not be able to be positioned. If it is fixed, its containing block would be the viewport, and then can be positioned.

I'd propose changing the point to positioned el is in a higher top layer than possible anchor and positioned el's containing block is the viewport or initial containing block.

[css-meeting-bot]

The CSS Working Group just discussed [css-anchor-position] Add containing block rules to acceptable elements in top layer, and agreed to the following:

• RESOLVED: No change, anchors in previous top layers is intentionally allowed.

The full IRC log of that discussion

<fantasai> TabAtkins: Rules for determing whether something is an acceptable anchor element, when talking about top layer
<fantasai> TabAtkins: if your positoined element is in top layer and anchor is in a previous top layer, it's acceptable
<fantasai> TabAtkins: Reason for this in spec is, our only requirement for being reasonable anchor is that it is fully sized and positioned before the abspos
<fantasai> TabAtkins: conditions are there to set up that situation
<fantasai> TabAtkins: top layers are defined to fully lay out atomically, so later top layer can depend on earlier top layers being fully laid out
<fantasai> TabAtkins: I'm not certain if OP is confused about conditions, or if pointing out something I'm missing
<fantasai> TabAtkins: pointing out case of positioned element is in a relpos dialog that is opened into top layer
<fantasai> TabAtkins: so dialog is in top layer, and anchor is in preceding top layer
<fantasai> TabAtkins: in the normal page, something outside your CB is never acceptable because not guaranteed to be laid out yet
<fantasai> TabAtkins: so limited there
<fantasai> TabAtkins: but that's because all in the same page
<fantasai> TabAtkins: but in this case, because separate top layers, no dependency because previous top layer is already laid out
<fantasai> TabAtkins: I think this is close no change, unless I'm missing something
<astearns> q?
<fantasai> astearns: propose no change, anchors in previous top layers is intentionally allowed
<fantasai> astearns: if we're wrong, OP will likely let us know?
<fantasai> kizu: No objection, but could we qualify this in the spec
<fantasai> kizu: when we talk about restrictions, if we talk about why we do this restriction
<fantasai> kizu: that way when you read it you understand
<fantasai> kizu: why it's different in this case
<fantasai> TabAtkins: I do have a note preceding the algorithm explaining its intent
<fantasai> RESOLVED: No change, anchors in previous top layers is intentionally allowed.

[jamesnw]

Apologies for the lack of clarity on this one. My request is that the spec be updated to reflect it as it is implemented in Chromium.

Current behavior in Chromium:

Given an element inside a top layer, if it is position: absolute, it can not find an anchor on a lower layer, because its containing block is the root element of its layer (the popover, for instance).

Given an element inside a top layer, if it is position: fixed, it can find an anchor on a lower layer, because its containing block is the viewport.

Here's a demo using popover-
https://codepen.io/jamessw/pen/KwKJJRJ

And a demo with a popover inside a dialog, again showing that an abspos element is currently unable to find an anchor in a lower layer.

https://codepen.io/jamessw/pen/YPzBBbE

Based on the conversation, am I understanding that this is instead an implementation bug, and the abspos examples should work?

[dshin-moz]

Would like to elaborate on what @jamesnw described - I'm actually unsure if the provided demo can be anchor positioned "for free."

Yes, a prev layer's anchor is guaranteed to be laid out, but the containing block of the positioned element we're laying out isn't - Say there's a bunch of statically-positioned elements between the cb and the top popover element. Wouldn't that preclude us from positioning the anchor element w.r.t. containing block in question?

Following that, I don't think we can position against an anchor that is not a descendant of the positioned element's abspos containing block, at least not without introducing some sort of additional steps. OTOH, we can size against anchors in a previous top layer just fine, though I'm not sure if that's useful.

FWIW, fixedpos' CB is viewport, so the whole issue is sidestepped.

[tabatkins]

Hmm, okay, these CB rules weren't super clear to me. In particular, if nothing in the top layer intentionally creates an abspos CB, the abspos then relies on the ICB - where in the stack does that live? It looks like impls either implicitly cause the topmost elements of each top layer to generate an abspos CB, preventing it from reaching the ICB unless it's in the root layer

Then the fixpos containing block (the viewport) appears to be wrapping the entire hierarchy, such that anything could potentially be an anchor. Then the layer order is all that matters; a fixpos element in the root layer gets painted before any top layers, so it can't refer to a top layer anchor, etc.

So I propose we adopt the following:

• Each top-layer element generates an abspos containing block implicitly.
• The viewport CB is a parent of all layer's CBs, root and tops.