- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 24 Sep 2025 17:02:21 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-anchor-position] fallback-position behavior: spec vs. expectation`, and agreed to the following: * `RESOLVED: no change for the default, we'll investigate a switch` * `SUMMARY: Significant concern about re-running selection on scroll` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> fantasai: emeyer raised this. there was previously behavior differences in fallback choosing<br> <TabAtkins> fantasai: we were previously greedy with fallback behavior<br> <fantasai> TabAtkins: When you have multiple fallbacks, current spec behavior is to run through the list to pick the first one that doesn't overflow<br> <fantasai> TabAtkins: If layout changes such that an earlier option would now be valid, current spec doesn't go back.<br> <fantasai> TabAtkins: it only changes which fallback is used when your current fallback choice stops being valid<br> <fantasai> TabAtkins: then it re-evaluates the list again<br> <fantasai> TabAtkins: Alternate behavior is to check after every layout<br> <fantasai> TabAtkins: so that you're always taking the most favorable option, if it is valid<br> <emeyer> q+<br> <fantasai> TabAtkins: This "greedy" behavior is what WebKit did have earlier, but spec has for some time focused on "stable" version<br> <fantasai> TabAtkins: Eric noticed the different and ran some polls on what they prefer<br> <fantasai> TabAtkins: Respondants seemed to strongly prefer the "greedy" behavior<br> <fantasai> TabAtkins: If you resize an element such that first element causes overflow, and then the popover flips to the other side, then you widen element again, it still stays on that other side until you do something to make it invalid<br> <fantasai> TabAtkins: Preference was to flip back to the first option if possible<br> <fantasai> TabAtkins: fantasai and I discussed this, and a few points<br> <fantasai> TabAtkins: We thought the preferred behavior might differ based on whether you are responding to layout changes, or whether you are responding to something more passive like scrolling<br> <fantasai> TabAtkins: Also point out that you would need to re-run multiple anchor layouts every time layout changes if we went with "greedy" behavior<br> <astearns> ack emeyer<br> <fantasai> TabAtkins: which is therefore less efficient<br> <kizu> q+<br> <TabAtkins> emeyer: I ran the poll not because I had a preferred, but because I discovered there were two behaviors<br> <TabAtkins> emeyer: when I put up the epoll I expected it to be about 50/50<br> <TabAtkins> emeyer: it wasn't, which is why I opened the issue<br> <TabAtkins> emeyer: even in the small poll there was such a strong tilt<br> <TabAtkins> emeyer: there are arguments in both the poll and the issue for both behavior<br> <TabAtkins> emeyer: roman and I are probably in agreement that this should be switchable<br> <TabAtkins> emeyer: as some people say, they'd prefer that, for a given layout state, the popover should always be in the same place regardless of history<br> <TabAtkins> emeyer: in my slider example, a given slider position should always give a consistent label position<br> <TabAtkins> emeyer: while a11y people said having things jump around more is an a11y problem<br> <TabAtkins> emeyer: I don't think I have a strong preference but it needs to either be more clearly explained, or given authors an option<br> <astearns> ack kizu<br> <TabAtkins> kizu: I think we definitely need an option. each version has pros and cons<br> <TabAtkins> kizu: I think current spec behavior is okay as default if it has better perf and makes less layout jumps<br> <TabAtkins> kizu: but as seen by the poll, people do expect greedy behavior. it's what the libraries do.<br> <emilio> q+<br> <TabAtkins> kizu: and it'll be needed for migrating from those js libraries, as the beahvior change might not be wanted<br> <TabAtkins> kizu: so I think current spec is okay for default if there's an option to have a less stateful version<br> <astearns> ack emilio<br> <emeyer> +1 to everything kizu just said<br> <TabAtkins> emilio: I'd rather stick with the current spec behavior rather than having an option<br> <TabAtkins> emilio: this option would mean running layout on scroll every time you're in any fallback beyond the first<br> <TabAtkins> emilio: which is annoying<br> <TabAtkins> emilio: for a small tooltip that's probably fine, but a sidebar, something big that's in a fallback state most of the time, that's not great<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: I think I agree with Emilio that running the choice algo on scroll is a bad idea<br> <TabAtkins> fantasai: definitely not default to it<br> <TabAtkins> fantasai: but for cases where you're running layout anyway, re-evaluating might not be that bad<br> <TabAtkins> fantasai: so i'd be open to allowing greedy behavior but not for scroll. only for CB changes<br> <TabAtkins> astearns: i'm hearing even the folks that want a switch are fine with current default<br> <TabAtkins> astearns: should we resolve to use the current spec text as default, explore a switch in the issue?<br> <TabAtkins> +1<br> <Kurt> +1<br> <fantasai> https://www.w3.org/TR/css-anchor-position/#position-try-order-property<br> <TabAtkins> fantasai: a place to have the switch is probably in position-try-order<br> <TabAtkins> astearns: proposed resolution is no change for the default, we'll investigate a switch<br> <TabAtkins> astearns: objections?<br> <TabAtkins> RESOLVED: no change for the default, we'll investigate a switch<br> <TabAtkins> emilio: can we resolve on not being greedy on scroll changes?<br> <fantasai> SUMMARY: Significant concern about re-running selection on scroll<br> <TabAtkins> astearns: we'll discuss whether we have the greedy switch at all<br> <TabAtkins> emilio: ok<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12682#issuecomment-3329882855 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 24 September 2025 17:02:22 UTC