[csswg-drafts] [css-anchor-position-1] inset-inline-start: anchor(start) is confusing (#13734)

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

== [css-anchor-position-1] inset-inline-start: anchor(start) is confusing ==
I was debugging https://codepen.io/editor/argyleink/pen/019c1f28-bbc2-7bac-ad4a-a7e41d3730f1 which uses the following pattern:

```
        inset-inline-start: anchor(start);
```

and this is actually causing some problems because the author is expecting this to align the start edge of the anchored box to the corresponding edge of the anchor. (Reasonable!)

Except it doesn't do that, because logical properties are resolved according to the writing mode of the abspos itself, whereas the anchor() sides are (currently) resolved against the writing mode of the abspos's containing block.

We did add `self-start`/`self-end` keywords to have that functionality, but it doesn't seem to be intuitive to make that extra leap of logic.

Should we make anchor(start)/anchor(end) resolve using the same writing-mode as the logical inset properties themselves?

I could maybe see an argument for wanting everything to resolve using the container's writing-mode, which is what `position-area` does; but we can't do that (because the insets can only resolve against the element's own writing-mode). And I'm having a hard time thinking of a case where you would want anchor(start) to resolve using the containing block's writing mode given that the insets themselves are either physical or logical against the element's own writing-mode.

CC @argyleink @jfkthame @jakearchibald 

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


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

Received on Friday, 27 March 2026 01:18:08 UTC