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

> Sorry for the delay, [@mstensho](https://github.com/mstensho) .
> 
> Yeah, Blink appears to be violating the spec, tho that might be a reasonable thing to do. I put in the restriction of "only recalculate on overflow" in the hopes of keeping it cheaper (you reevaluate only at the times that you would have _previously_ re-evaluated, you just record a little more data when you do so), but if Blink considers it acceptable to redo all the layout calculations once per frame, that's probably better for authors and users? Have we actually tested to make sure this has acceptable perf, particularly in complex cases (several chained anchorpos elements), or did the impl just do something simple and didn't check the perf beyond the simple case?

I didn't work on anchor positioning when the current implementation was written, so I can't answer very confidently. But I've been assuming that the hard limit on the max number of try options per element (it is 6 in Blink) wouldn't cause unreasonable performance. Anyway, this is really only "scary" if there are chained anchor positioned elements, and some non-default position-try-order, in which case there might be some O(n^m) performance complexity (where `n` is the number of options, and `m` being the length of the anchor chain). 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).

If `position-try-order` is `normal`, on the other hand, this matters.

Imagine an anchor, and then a small positioned element that is placed above the anchor, with a fallback of placing it below the anchor. As long as it fits above, it will be placed above. If the document is scrolled so that it no longer fits above, it will go below. 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)

I was kind of hoping for B, since that would make it easier (or simply possible?) to let a (fallback) option change be an "anchor recalculation point". See example in https://github.com/w3c/csswg-drafts/issues/10999#issuecomment-2507266529 . Option B also introduces some statefulness, in that a given scroll offset doesn't always result in the same position option; it depends on where you come from. The good thing about it is more option stability. Why should we move away from an option that still fits, even though there's an option higher up on the list that fits?

... which brings me to another question: 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?

> > This part of the spec also seems oblivious to the fact that there may be a specific try order (let the tallest one win, for instance), which complicates the story and calls for further clarifications. It starts with "When a positioned box (shifted by its default scroll shift) overflows its inset-modified containing block", which won't do if position-try-order wants us to consider all viable options and stable-sort them. We cannot wait until it overflows then.
> 
> I'm not sure what you mean by this, tho. You calculate the IMCBs for each try-option, order them according to position-try-order, then try to lay out the anchorpos into them. Then you just wait until the anchorpos overflows before you redo any of these calculations. Per the spec, how does position-try-order complicate this? I can see how _Blink's behavior_ makes it more complicated, but that's not the spec's fault as currently written. ^_^

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?

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


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

Received on Tuesday, 11 February 2025 22:42:51 UTC