Re: [csswg-drafts] [css-anchor-position] fallback-position behavior: spec vs. expectation (#12682)

Some additional points here:

* The current "stable" behavior means we only need to reevaluate position-try when the positioned element overflows; the "unstable" version would require us to reevaluate it on *any* change. Given that nested anchor positioning can potentially incur butexponential costs (and the spec has a guard against that), this might be a perf issue; it might require a more aggressive limit on position-try counts. (But in the common case you're not nested, so this is much less of a concern.)
* [As Ian alludes to in their comment](https://github.com/w3c/csswg-drafts/issues/12682#issuecomment-3237800389), people might have different expectations for "abspos started in position 1, then moved so it switched to position 2, then moved back so I want it in position 1 again" vs "abspos started in position 2 (because position 1 would have overflowed), then moved so that position 1 was possible" - in the latter case the intuition might lean more toward the current spec's stability.

Authors also might have different expectations for area changes based on *scrolling* vs *layout* - dragging an element around (that is, actually changing its style) might lean people towards the "unstable" version (as it's what you'd get if you refreshed the page with those styles), while just scrolling might lean people towards the "stable" version (to reduce flickering while users are scrolling).

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


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

Received on Friday, 12 September 2025 22:48:39 UTC