Re: [csswg-drafts] [css-anchor-position-1] Back-compat of scrollable containing block for all abspos with implicit anchors (#13067)

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.

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


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

Received on Thursday, 6 November 2025 00:23:56 UTC