[css-anchor-position-1] inset-inline-start: anchor(start) is confusing

[fantasai]

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 @kizu

[argyleink]

iiuc, a logical inset and a logical anchor() inset, for the same anchoring element, currently have the potential to resolve against different writing modes? a containing block could be ltr and the element could be rtl, at which point inset-inline-start for example would each resolve to something else depending if it's anchor inset or position inset? i suppose that makes sense… but is quite a potential gotcha.

while the mentioned self-start/self-end could resolve some scenarios, there's others that need calc() and they can't quite tap into that beneficial edge case handling can they? not sure most web developers are going to be able to juggle distinguishing their containing block language modes vs their element language modes, aligning anchor inset to the element (target of the anchor) writing mode makes the most sense to me (at least right now in my current understanding).

[tabatkins]

The issue is just that we definitely want to allow both references (the anchoring element and the containing block), and we already have a pretty well-established precedent of how to name the two values in that pair, which AnchorPos uses.

I know it's a tradeoff of understandability, but I lean toward the current spec where we rely on the existing pattern, even if it can cause some confusion if you're not careful. I think that's a better potential-confusion than having to learn that in some properties you distinguish between the element and its CB with start and self-start, and in other properties you distinguish between them with start and cb-start or whatever.

@argyleink All logical property names interpret their directions on the element itself. But logical property values can vary, and often instead refer to the containing block (so multiple children can act the same, even if they have different writing modes from each other), with self-start/etc used to specifically opt into using the element's own direction.

[fantasai]

@tabatkins I think this is going to trip people up a lot. It's totally not at all obvious that inset-inline-start: anchor(start) can give you any one of these combinations:

• left: anchor(left)
• right: anchor(right)
• left: anchor(right)
• right: anchor(left)

You're matching directional keywords in your code. The fact that you can get a mismatched result is not going to be expected and I suspect will result in user errors far more often than it will result in the correct thing. I mean, I can't even think of a case where this would be the desired result.

[tabatkins]

I mean, that's the problem with logical directions! They rely on a not-obvious-at-the-source directionality, and there are (at least) two valid things they can draw from (sometimes three).

The exact same potential confusion applies to, say, position-area, which similarly uses start to refer to the CB and self-start to refer to the element itself. If you set position-area: inline-start;, and then use inset-inline-end: 10px to (you believe) push yourself 10px away from the anchor, you might run into the exact same problem, where your CB might have an opposite direction, you're actually put on the opposite side from what you expect, and you're still flush against the anchor (the 10px offset is keeping you from touching the CB's side, instead).

These two anchor-pos usages (position-area: start and anchor(start)) absolutely have to refer to the same directions, imo, or else it's just totally confusing. And this happens to be consistent with every other usage of start/self-start, like in background-position and others.

(The logical inset properties are perhaps a little misnamed, but iirc it's not reasonably possible to have a property name resolve to a direction based on the CB, as that's a layout-tree-time construct and too late for how we want to think about the physical/logical property pairings. We specify this explicitly in CSS Logical; property names are always resolved to physical values according to the element itself, so we just always use the -start naming for them.)

[Loirooriol]

I think it was a mistake to make start and end refer to the CB in css-logical and css-align. They should refer to the self, and then have cb-start instead of self-start.

But now that we have this pattern (and I'm guessing it's too late to change it), I agree with Tab that using a different pattern for anchor positioning would probably make things even more confusing.