Re: [csswg-drafts] [css-anchor-1] Issues with position fallback (#8059)

Wait, 1 actually doesn't work.

Think about a long document with:
- Anchor element initially not in the viewport
- A fixpos OOF with two fallback positioning: first above the anchor, then below the anchor

```html
<style>
.spacer { height: 1000vh; }
#anchor { anchor-name: --a; }
#oof {
  width: 100px; height: 100px;
  position: fixed;
  position-fallback: --pf;
  anchor-scroll: --a;
}
@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 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.

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.

-- 
GitHub Notification of comment by xiaochengh
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8059#issuecomment-1314657467 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 15 November 2022 02:05:45 UTC