[csswg-drafts] [css-anchor-position-1] Back-compat of scrollable containing block for all boxes with implicit anchors (#13067)

fantasai has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-anchor-position-1] Back-compat of scrollable containing block for all boxes with implicit anchors ==
In <https://github.com/w3c/csswg-drafts/issues/12552#issuecomment-3210696721>, we resolved that, if you have a "default anchor element", and your CB-generating element is a scroller, you use the “scrollable containing block” (aka the size of the scroller's entire contents) rather than the “local containing block” (the size of the scrollport, like the ICB). This allows multiple anchor-related features to work better wrt overflow alignment and `position-try` fallback, as the local CB is nonsensical to use for anything that starts out “below the fold”.

However, this creates both backwards-compatibility and forwards-compatibility issues because it changes the positioning of abspos boxes that have an implicit anchor, whether or not they are using anchor-positioning features.
1. It would cause us to change where boxes with, for example, `bottom:0` or `right:0` are placed if they are currently defined to have an implicit anchor (e.g. are a) popovers or b) `::before` or `::after`).
2. It would create this same Web-compat issue for adding an implicit anchor relationship in the future to any other already-existing elements.

After discussing how to work around this, Tab and I have the following proposal:
* Revert the resolution to make the scrollable CB key off of *just* whether or not there is a default anchor. Instead, key it off of having a default anchor *and*  using `position-area` or `anchor-center`. This ensures that these features work as expected.
* Keep using the local containing block for all other abspos boxes and for resolving their insets, but redefine `auto` to calculate the inset-modified CB edge to match the corresponding scrollable CB edge. This ensures that positioning setting one inset with `anchor()` and leaving the other `auto` (the common case) will get a useful CB for calculating `position-try` overflow, without changing the positioning behavior of any existing abspos usage that *isn't* using `position-try`.

We think this would preserve the existing behavior of abspos boxes while ensuring that positioning, alignment, and `position-try` fallback of anchor-positioned boxes behaves as expected, for `position-area`, `anchor-center`, *and* `anchor()`. (Thus, for the three cases given by the testcase in <https://github.com/w3c/csswg-drafts/issues/12952>, they would all still position over the --bottom anchor, as intended, neither triggering `position-try` fallback nor alignment-safety shifting.)

We might also consider, for abspos in general, making the “scrollable containing block” be the “original containing block” (while keeping the “containing block” as the “local containing block”), so that we only trigger overflow alignment safety against the “scrollable containing block”, where it is actually needed.

Thoughts?


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13067 using your GitHub account


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

Received on Wednesday, 5 November 2025 22:41:11 UTC