- From: Morten Stenshorne via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Jan 2025 12:17:12 +0000
- To: public-css-archive@w3.org
@tabatkins Can you comment on this, please? This got introduced by commit 99403a8635fae054845320ea5f1453977c84e231. The spec should be more clear, whether my reading of the spec is right or not. I'm talking about the wording in https://drafts.csswg.org/css-anchor-position-1/#fallback-apply , and how it suggests that the UA should only consider switching to a new option when the current option no longer fits (shouldn't matter whether it's currently at the "default" option with unmodified styles, or at a fallback option defined in `position-try-fallbacks`?). What Blink currently does: Every time the options are being reconsidered, we'll just start at the first option, and go through them all until we've found something that fits (or, if `position-try-order` requires us to, we'll go through them all, and stable-sort them and pick the best one), meaning that if we're at a fallback position, and a preceding option suddenly fits, the preceding option will be chosen, regardless of whether the current fallback option fits. 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. -- GitHub Notification of comment by mstensho Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10999#issuecomment-2621484757 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 29 January 2025 12:17:13 UTC