[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.

[xiaochengh]

A new idea to make it work better with scrolling:

For each fallback position, we can calculate a scroll-adjusted inset modified containing block, defined as follows:

1. For each inset property, its scroll-adjusted inset is
   • auto if the property value is auto
   • Otherwise, the original property value offseted by the value of snapshotted scroll offset in the same axis
2. The scroll-adjusted inset modified containing block is calculated using the same algorithm as inset-modified containing block, but replacing the original inset property values by the scroll-adjusted insets
3. The fallback position is valid if the margin box of the element, shifted by the snapshotted scroll offset (if any), falls in the scroll-adjusted inset-modified containing block

We can easily run this through my previous test case and verify its correctness.

Intuitively, we are still folding scroll offset into inset value evaluation; however, we are not folding it deep into each anchor() function, but at a very shallow level at the end of the evaluation. In other words, any non-auto inset property value is shifted as a whole by the scroll offset.

This still won't cause layout invalidation in every scrolling, and hence still supports composited scrolling. When scrolled by an amount, both the margin box and certain edges of the scroll-adjusted inset-modified containing block will be shifted; Note that they are always shifted by the same amount. Therefore:

• If an inset property value is not auto, we just need to check if the margin box overflows this edge at the initial scroll position -- if it doesn't, it means the element will never overflow this edge regardless of how we scroll, and vice versa
• If an inset property value is auto, then this edge of the inset-modified cb is at a fixed location independent of scrolling; Then we can also work out the range of scroll offsets that doesn't overflow this edge

So in the end, for each fallback position, we can still work out a range of scroll offsets, which forms a rectangle, in which the fallback position is valid. We trigger relayout only when we scroll out of this range.

[tabatkins]

Okay, I believe I've accurately translated your suggestion into spec text. ptal?

[xiaochengh]

There's a still a minor bug, though it's probably an edge case.

If the target element has 0 size, then it can still fit in the scroll-adjusted IMCB even when it's out of the original containing block -- this happens when the SAIMCB is collapsed and also out of the original CB. (e.g., with top: 1000000px; bottom: auto and 0 scroll offset).

To fix it, we can require that the scroll-shifted margin box must be in both the SAIMCB and the original CB.

(Equivalently, we can skip the final clamp-negative-size-to-zero step at the end of the SAIMCB calculation -- then the 0-sized element can't fit in a negative-sized SAIMCB; this requires more complicated spec text but is simpler to implement)

[xiaochengh]

Talked to @tabatkins offline. Here's the stuff we agreed to add to the spec:

• Define scroll-adjusted IMCB as the output of the IMCB algorithm with scroll-adjusted insets (same as before), but without the final clamp-negative-size-to-0 step
• A fallback style is valid if after applying its application, the result margin box, shifted by the snapshotted scroll offset if any, is fully contained within the SAIMCB. Note that the SAIMCB may have negative size on one or both axes, in which case it's considered to not contain any point/box.
• We choose the first valid fallback style; or if all are invalid, choose the last one
• Each fallback style has a non-overflowing range, which is a closed 2D range (i.e., Cartesian product of two closed intervals), such that the fallback style is valid if and only if the snapshotted scroll offset falls in the range. The range is calculated as follows (with left as an example)
  • If the left property value is not auto, then the left edge of the SAIMCB has form L - scroll_offset.x, where L is constant to the scroll offset. Then:
    • If margin_box.left >= L, then the scroll-shifted margin box is always on the right side of the left edge of the SAIMCB, and the left edge of the SAIMCB does not impose any constraint
    • Otherwise, the SAIMCB never fully contains the scroll-shfited margin box, and the non-overflowing range is empty
  • If the left property value is auto, then the left edge of the SAIMCB is a value constant to the scroll offset; denote that constant with L. Then the left edge of the SAIMCB imposes a constraint scroll_offset.x <= margin_box.left - L
  • Similarly, from each other edge of the SAIMCB, we can either conclude that the non-overflowing range is empty, or possibly get a constraint
  • Finally, the non-overflowing range is either empty, or the conjunction of all the constraints we got above
• UA should not recalculate layout on every scroll change, but only when the snapshotted scroll offset has moved across the boundary of a non-overflowing range

[tabatkins]

Okay, made two fixes here.

1. Closed the loophole @xiaochengh mentioned, by simply auto-failing the fallback style if it resulted in a negative-size containing block.
2. Fixed the broken text I accidentally introduced in ab02227, while making some unrelated fixes. (The spec was, for some reason, changed to simply subtract the snapshotted offset from both the element and the CB before comparing them. This, obviously, doesn't actually affect the comparison's result.) We're back to allowing auto insets to work "correctly" when building the IMCB, for the purpose of overflow checking. (That is, we don't eagerly turn autos into 0, likely resulting in a busted IMCB with no relation to the anchor's actual position. Instead we shift the insets by the snapshot offset, then resolve autos, so if the anchor is scrolled into the range of the CB, the auto inset can actually produce a non-degenerate IMCB.)

[tabatkins]

It is still the case that the size of the element can't depend on scroll offsets† - its actual IMCB for layout purposes is still determined normally, based on the anchor's initial scroll position, so if the element is align-self: stretch; height: auto; or whatever, it'll get some possibly-useless size. But if the IMCB only determines its position, not its size, then things should work correctly again.

†: (The scroll offset can determine which fallback styles we're using, which can have an effect on the element's size, but that's not continuous variation like actually having the IMCB depend on the scroll offset would be. It'll just flip between a small set of fallbacks, and we're already okay with that being slightly desynced from composited scrolling; it's much less obvious than having something that's, say, supposed to stretch from a scrollable anchor to the bottom of the screen and always be the correct size to fill that space.)