[css-anchor-position] Scrollable Containing Block + Fallbacks/`position-visibility: no-overflow` & visibility of positioned element to users

[dshin-moz]

So, we started using Scrollable Containing Block for things with default anchors, as of #12552 (comment).

This makes sense in terms of anchors that are initially positioned outside of the viewport/scrollport, but I think in some other cases, the behaviour is a bit counter-intuitive (With or without changes proposed in #13067, I think?). Given this example:

• First scroller, using the scrollable containing block along with a block-direction fallback, on both Chrome and Safari, the fallback never seems to trigger. That said, WebKit seems to initially use the fallback?
• Second scroller, equivalent to using Local Containing Block, triggers whenever the positioned element would overflow the scroller. I think this is intuitively what is expected - It seems odd that the first example can have the anchor element in full view but the positioned element hidden out of users' view, even if fallbacks are available.

... That said, as far as position-visibilty: no-overflow, things seem trickier.

• Third scroller, using the Scrollable Containing Block, the visibility never toggles. Though, one could argue the positioned element clipping by the scrollport is a graceful enough fallback.
• Fourth scroller, using the Local Containing Block equivalent, the bottom of the position-area grid has a height of 0, making the positioned element always overflow, therefore never showing the positioned element.
• Fifth scroller, using anchor functions instead, seem to work the most "as expected."

Overall, I think the evaluation of fallback and visibility should be more based on the ultimate visibility of the positioned element to the users, which would seem to involve checking overflow against the local containing block. FWIW, given the fourth scroller, it feels like use of Scrollable Containing Block is still valid for at least generating the position-area grid...