- From: Morten Stenshorne via GitHub <sysbot+gh@w3.org>
- Date: Thu, 13 Feb 2025 22:30:30 +0000
- To: public-css-archive@w3.org
> > 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, This is the part that I had missed. The spec is clear about it, and this is also what the implementation currently does. Yet, I managed to get confused. Thank you! > > 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). Very good! This is what I needed to know. If you want to review (or just check out) the tests that I'm adding and modifying, take a look at https://chromium-review.googlesource.com/c/chromium/src/+/6198263 > > 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). Great. Maybe e.g. the term "position fallback styles" in the spec could be changed to make this clearer, since it's not necessarily about one of the fallbacks. Might just be the base style as well. > > 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). Right, this is the part that I had misunderstood, which you cleared up in a previous paragraph here. > 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. ^_^ I think we're finally on the same page. I was supposed to implement some new functionality, which was very confusing thanks to discrepancies between the spec and the implementation when I arrived in this land. Thank you for explaining! -- GitHub Notification of comment by mstensho Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10999#issuecomment-2657845615 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 February 2025 22:30:31 UTC