Description
With the inset-area (https://drafts.csswg.org/css-anchor-position-1/#inset-area) starting to taking shape in the Chrome Canary as a prototype, I've started playing with what we have there now. It is still missing a few things for proper testing, but I think I already have one idea that might be interesting to think about: what if we will allow specifying an explicit “containing block” which is used for the 3×3 grid of inset-area?
With anchor() values for insets, we can use any anchors for calculations, but with inset-area we're limited to our anchor-default (which we can configure), and the containing block, which we cannot. But what if we could?
I think the main use case might be “escaping” an ancestor with position: relative, and choosing a different containing block instead (probably with some keyword to choose the viewport?). I can also imagine some curious interactions that can come up from using a containing block that is intersecting with our anchor element, or for cases when they're in entirely different places, especially when the fallbacks could get involved.
This might clash slightly with reparenting, but I think it might be worth it making a part of anchor positioning (probably just using some other anchor name for the containing block? Similar to how there is now specified fallback bounds which allow using another anchor for the fallback stuff https://drafts.csswg.org/css-anchor-position-1/#fallback-bounds)