[css-anchor-position-1] relaxing abspos ordering requirement for acceptable anchor elements

[fantasai]

See https://bsky.app/profile/chriscoyier.net/post/3mg4ciead622j from @chriscoyier. Can we make this work?

[jensimmons]

Here's more: https://frontendmasters.com/blog/the-big-gotcha-of-anchor-positioning/

[bfgeek]

This gets into very difficult issues very quickly unfortunately.

I've previously thought about this fairly deeply - e.g. if we could sort things ahead of time to determine a better order, but the only thing that works reliably is tree-order unfortunately.

First off cycles are possible:

<div style="position: absolute; anchor-name: --a1; top: anchor(--a2 top);"></div>
<div style="position: absolute; anchor-name: --a2; top: anchor(--a1 top);"></div>

For these types of cases you need to rely on tree-order to break the cycles.

To that you might say "ok if something doesn't have any anchor references on itself then layout that first".

<div style="position: absolute; anchor-name: --a;"></div>
<div style="position: absolute; top: 50px;"><container-query><div style="anchor-name: --a"></div></container-query></div>
<div style="position: absolute; top: anchor(--a bottom);"></div>

Anchors can be anywhere within a subtree, and you don't know what anchor-names it might have until after you've laid-out that subtree (the 2nd anchor in the above anchor may appear/disappear depending on the container-query evaluation).

Changing the order of the first two divs in the above example will result in different layout.

To that you might say - "ok I'm fine with breaking above just adjust objects being laid out by the containing block based on their top level styles".
First off - compat, second consider:

<div style="transform: translate(1px, 1px);">
  <div style="position: absolute; anchor-name: --a;"></div>
  <div style="position: absolute; top: 50px;"><container-query><div style="position: fixed; anchor-name: --a"></div>. </container-query></div>
  <div style="position: absolute; top: anchor(--a bottom);"></div>
</div>

Again abspos elements may appear/disappear due to their parent changing size, the fixedpos above may appear/disappear in the containing-block list based on how the container-query evaluates. Again tree-order is somewhat the only thing that makes sense here.

Additionally due to position-try-fallbacks you can switch between being anchor-positioned and not depending on what fallback you use (you may have a fallback that doesn't reference any anchors and visa versa).

So what to do.

Note this issue is typically the "worst" when you have abspos referring to other abspos. This broadly isn't an issue for abspos referring to an inflow as the inflow will always be laid-out first. E.g. you are more likely to run into this for demo building purposes counter-intuitively.

However a lot of the advanced usecases (chaining abspos off other abspos, see https://meyerweb.com/eric/thoughts/2023/09/12/nuclear-anchored-sidenotes/#fixing-proximate-overlap , or nested menu logic) work due to the tree-order rule.

Any change that we do here has to consider these various cases very carefully to make sure we aren't breaking other use-cases.

In summary a set of constraints:

• You don't know if an abspos sub-tree has valid-anchors until you've performed layout.
• You don't know the full set of abspos elements as abspos elements may add more abspos.
• Position fallbacks may change if you are anchor positioned or not.
• We can't refer to elements outside the containing-block tree.
• Compat risks (anchor positioning adoption is relatively quick for a new feature).

Broadly speaking devtools for abspos needs to get far better. They suck. A short list of issues I wish browsers (any browser!) would fix:

• Show the actual containing-block element which an abspos is positioned relative two upon hover in elements panel.
• Show the computed IMCB upon hover in the elements panel.
• Visualize the valid anchors better, and/or better tooling for why something isn't visible.

Ian