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

Sorry for the delay, @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?

> 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. ^_^

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10999#issuecomment-2652018719 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 20:39:55 UTC