[css-anchor-position-1] Back-compat of scrollable containing block for all abspos with implicit anchors

[fantasai]

In #12552 (comment), 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 #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?

[bfgeek]

So there are a lot of subtitles to get right wrt. resolving auto in this way. The behaviour of position-area and anchor() should be as close as possible.

IMO I feel very strongly[1] that we should just key off an anchor() function being present. E.g.

Instead, key it off of having a default anchor and using position-area or anchor-center or anchor().

There are a few different ways this could be defined, but the best would likely be if any anchor() was used when evaluating the insets/style.
(any anchor() value needs to be resolved relative to the final containing block used (scrollable for local) - so this needs to be for all anchor()).

(From speaking with Tab) When this was last-discussed there where a few concerns with this approach (I think these concerns came from no default anchor found as well):

1. As anchor functions are resolved at computed value time, you've "lost" if there was an anchor function even there.

IMO This isn't really a large concern, we should be able to plumb this information through to layout, it just depends how we want to specify how this works. Any anchor() being resolved should be fine.

2. Some hesitation about top: anchor(bottom); bottom: 0; and top: 0; bottom: 0 resolving bottom: 0 differently.

IMO this isn't a concern. With align-self: center vs. align-self: anchor-center you'd also get a large difference in behaviour (different available sizes, potentially large difference in element width).

You'd also get a large behaviour difference if you used inset: 0; position-area: none and inset: 0; position-area: bottom for example.

Ian

(Also for popover specifically this isn't a large concern as they have position:fixed by default).

[1] To the point I'd potentially object.

[bfgeek]

Additional points:

1. As anchor functions are resolved at computed value time, you've "lost" if there was an anchor function even there.

This point is also an issue for the proposed solution of adjusting the auto inset. E.g. if just using the computed style, you need to capture that an inset was resolved by an anchor() function at CVT.

Another issue with adjusting the auto inset is that its confusing if the developer does set the other inset. For example:

<!DOCTYPE html>
<div style="position: relative; width: 100px; height: 100px; overflow: scroll;">
  <div style="width: 200px; height: 200px;">
    <div style="margin-left: 20px; margin-top: 20px; width: 50px; height: 50px; background: hotpink; anchor-name: --a;">
      anchor
    </div>
    <div style="position: absolute; position-anchor: --a; left: anchor(right); top: anchor(top); background: lime;">
       text text text text text
    </div>
  </div>
</div>
<!-- https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=14299 -->

Then lets say the web-developer "oh I want to leave space of 10px on the right" and sets right: 10px this radically changes the layout.

[bfgeek]

Another potential solution to this problem is to use the "scrollable containing-block" if there is a non-implicit default anchor. E.g.

This doesn't really matter for popover as it is position:fixed by default, and doesn't use the scrollable containing-block.

And would satisfy the forwards compat constraint in adding implicit anchors to different things, etc (and I suspect most of those things would be position:fixed for example.

Additionally the "local containing-block" is likely fine for ::before/::after as they are typically fixed-size and are typically used for decoration elements.