[css-anchor-1] Issues with position fallback

[xiaochengh]

In a discussion with @bfgeek today we identified some issues about how position fallback is currently specified.

1. For each fallback position, there should be an additional criterion that the margin box rect of the element (without scroll adjustments) should not overflow the inset-modified containing block. This is for some use cases (like below) where the element doesn't overflow the containing block, but instead overlaps with the anchor, which is still undesirable.

<style>
#anchor {
  anchor-name: --a;
  margin-left: 20px;
}
#anchored {
  position: fixed;
  top: anchor(--a top);
  width: min-content;
  position-fallback: --pf;
}
@position-fallback --pf {
  @try { left: 0; right: anchor(--a left); }
  @try { right: 0; left: anchor(--a right); }
}
</style>
<div id=anchor>anchor</div>
<div id=anchored>some very loooooooooooooooooooooooong content</div>

2. We still need to make sure the scroll-shifted margin box doesn't overflow the original (not-inset-modified) containing block. But the spec isn't clear which box of the containing block to compare to: content, padding or border box? Content box makes the most sense to me.

[tabatkins]

1. Ah yes, that makes sense. Happy to add in that condition.

2. Containing block is a rectangle, not a box; it's generated by some box (and we have a shorthand where you can refer to properties of the containing block and actually mean the properties of the box generating it). For an abspos, the containing block is defined by https://w3c.github.io/csswg-drafts/css-position-3/#def-cb

[xiaochengh]

Wait, 1 actually doesn't work.

Think about a long document with:

• Anchor element initially below and to the right of the viewport
• A fixpos OOF with two fallback positioning: first above the anchor, then below the anchor
• The OOF's left side is anchored to the left edge of the anchor

<style>
.spacer { height: 200vh; }
#anchor {
  anchor-name: --a;
  margin-left: 200vw;
}
#oof {
  width: 100px; height: 100px;
  position: fixed;
  position-fallback: --pf;
  anchor-scroll: --a;
  left: anchor(--a left);
}
@position-fallback --pf {
  @try { bottom: anchor(--a top); }
  @try { top: anchor(--a bottom); }
}
</style>
<div class="spacer"></div>
<div id="anchor"></div>
<div class="spacer"></div>
<div id="oof"></div>

After scrolling the anchor element into viewport, we expect to see the OOF above the anchor

However, if we follow the behavior of 1, then for both fallback positions, the inset-modified containing block rects collapse into a line; and then both fallback positions will overflow the inset-modified containing block. Then we always end up using the last fallback position because we've run out of fallbacks.

To fix it, we probably need to once again include scroll offset into anchor() when calculating the inset-modified cb. But this once again means every scroll change can possibly invalidate layout, leaving no room for composited scrolling.

If there's no good fix to 1 that still allows composited scrolling, it should be no longer considered.

[bfgeek]

However, if we follow the behavior of 1, then both fallback positions will overflow the inset-modified containing block (because top/bottom will evaluate to something around 1000vh, making the available space empty). Then we always end up using the last fallback position.

For the scroll behaviour - wouldn't we test if the element is overflowing the contianing block (similar to sticky-pos). E.g. that part of the calculation wouldn't depend on the inset-modified containing-block?

[xiaochengh]

Discussed with @bfgeek offline:

• We still want to involve the inset-modified containing block rect (or some variation of it) for position fallback, because overlapping with anchor in some trivial cases is bad
• The inset-modified rect (or variation) should not involve scroll offsets. We don't see how it can ever work otherwise
• We still need more work on this idea to support cases like the one I gave in the last comment

One idea is to somehow (conceptually) turn the fallback positions into, e.g.

@try { left: anchor(--a left); right: calc(anchor(--a left) + 100vw); }

In other words, if one side of the inset-modified rect has anchor queries and the other side is auto, then we adjust the other side to fit in the OOF.