Re: [csswg-drafts] [css-anchor-position] Better handling of scroll position for fixpos elements on first layout (#10999)

> And if there's non-default position-try-order, we have to always try them all anyway, regardless of how the spec is interpreted (cannot wait for overflow then).

I don't understand what you mean by this. There should not be any difference in behavior between 'normal' and the other values in this regard. Yes, you calculate all the IMCB sizes so you can sort them (rather than being able to skip some), but that still only happens when you're re-choosing the position, and when *that* happens doesn't depend on position-try-order. If you're switching positions due to scroll, that's only triggered by overflowing the scroll-adjusted IMCB size. 

> If the document then is scrolled just a few pixels back up, so that the element would fit above the anchor again, should we:
>
> A: Move the element above the anchor unconditionally (current behavior in Blink)
>
> B: Leave it below the anchor if it still fits there (the way I read the spec)

You read correctly, it should stay below, because you're not triggering a position recalc; you won't until the element actually overflows again. This stability is an intentional feature, both for perf (less recalcing) *and* for UX (less shifting around when it's not strictly necessary).

> is the position derived from the base style so special, compared to any fallback options? In the end, aren't they all just options, albeit in a preferred order? Does it make sense to talk about fallbacks vs base style at all?

It's not special, it is indeed just the first among several options (and not even first, if position-try-order dictates a different ordering).

> You can't wait for overflow if you always want to pick the tallest option. Which one is the taller one may change as you scroll (the IMCB changes when you scroll), even if the current option doesn't overflow.
>
> Does that make sense?

In a vacuum, sure, but that's not what the spec says or intends. It *doesn't* want to always choose the tallest option, it wants to know the tallest option *when it's time to re-determine position* so it can try to put the element there first.  Then it stays with that option until there's a reason to change (the element overflows).

I feel like we've been talking past each other because the impl does something violating the spec, and you've been working under the assumption the impl was correct. ^_^

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


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

Received on Wednesday, 12 February 2025 21:49:45 UTC