[csswg-drafts] [css-anchor-position-1] Allowing to explicitly define the containing block for inset-area (#9662)

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

== [css-anchor-position-1] Allowing to explicitly define the containing block for inset-area ==
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)

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


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

Received on Thursday, 30 November 2023 21:53:00 UTC