Re: [csswg-drafts] [css-anchor-position] Allow a positioned el's containing block to be the anchor (#11769)

> Isn't this already the behavior? If it gets placed within a position grid row or column with a zero size, the positioned element doesn't get clipped.

I meant escape to to a different containing-block.

Part I of my unease is if we have something like:

```
<style>
my-component {
  anchor-name: --my-component;
  position: relative;
}
</style>
<my-component>
  <content-content>
    <my-component></my-component>
  </content-content>
  <abspos style="position-anchor: --my-component"></abspos>
</my-component>
```
E.g. nesting components + anchoring to them becomes unfeasible.

Part II of my unease is it encourages the zero available size tracks - which in a lot of cases isn't desirable. (IMO devtools need to be substantially better in all browsers to show the CB & IMCB - but thats a discussion for another day).

Part III is the integration with things like: https://github.com/w3c/csswg-drafts/issues/10861

I think there might be an argument for better referencing of CB edges, e.g. you can do all this today, e.g. `left: 100%` for example to be at the RHS of a CB, perhaps some helpers here would be useful.

> Interesting- so potentially, if an abspos element with a default anchor can't find an anchor within its containing block, it would look higher in the tree to find a containing block, and then its parent would become a valid anchor as a descendant of the altered containing block? This could provide better behavior potentially, although I'm hesitant to introduce more complexity into the containing block algorithm.

Thats right - yeah potentially too complex. But letting an abspos skip containers I have heard as a usecase people want to do.

(As an aside devtools also need to describe the CB relationship far better in devtools).


-- 
GitHub Notification of comment by bfgeek
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11769#issuecomment-2773428802 using your GitHub account


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

Received on Wednesday, 2 April 2025 18:53:00 UTC