[css-anchor-position-1] position-area: self keyword inconsistency

[tuankiet65]

The syntax definition of position-area says the self version of block-start, block-end, inline-start, inline-end is the same keyword but with the self- prefix (so self-block-start, self-block-end, ...).

However in the section explaining what the keywords mean, self is placed in the middle of the keyword instead of (block-self-start, block-self-end, ...)

So which of these is the correct convention to use?

This also leads to a relevant issue - in the syntax definition, we both have self- as the prefix (e.g: self-block-start, self-inline-start), and self- in the middle (e.g: x-self-start). Should we fix the syntax to be consistent where self- could be in the keyword?

[tuankiet65]

For some perspective, Chome implements it as exactly as the syntax definition says, and the WPT tests reflect it.

[tabatkins]

The position fo the self has a consistent reasoning - it's modifying the logical direction. So if the entire value is a logical direction, it prefixes the entire thing; if the value is half-logical, it prefixes the logical part.

Put another way, just as "block-start" is a logical direction, "self-block-start" is a logical direction, and we're just combining "x-" with a logical direction.

[css-meeting-bot]

The CSS Working Group just discussed [css-anchor-position-1] `position-area`: `self` keyword inconsistency, and agreed to the following:

• RESOLVED: x-self-start and self-block-start are correct, fix the spec

The full IRC log of that discussion

<fantasai> TabAtkins: We have both normal logical keywords and self-* logical keywords
<fantasai> TabAtkins: using either containing block writing mode or box's own writing mode
<fantasai> TabAtkins: Kiet pointed out that there's an inconsistency in the keywords about the placement of 'self'
<fantasai> TabAtkins: This was intentional on our part, because self- is not modifying the axis, but the direction
<fantasai> TabAtkins: x-self-start is combining physical direction and logical direction
<fantasai> TabAtkins: whereas self-inline-start is using self writingmode for both axis and direction
<fantasai> Kiet: Wanted to understand why it's the case. once I read Tab's comment, it makes sense
<fantasai> Kiet: So I think it's fine to keep it like that
<fantasai> Kiet: Another issue which is editorial is, in some places we use self-block and other places we use block-self
<fantasai> TabAtkins: Oh, indeed we do!
<fantasai> astearns: Is it just in anchorpos spec or others?
<fantasai> TabAtkins: just here
<fantasai> TabAtkins: but that is definitely an editorial mistake
<fantasai> fantasai: That raised the question of what was intended.
<fantasai> TabAtkins: Ohh, yeah.
<fantasai> TabAtkins: I think it still needs to be self-block-start, since it's interpreting the axis also per the self writing mode
<fantasai> TabAtkins: ...
<fantasai> TabAtkins: We did a copy-paste error probably
<ntim> I heard block as a verb :D
<ntim> block self start
<fantasai> astearns: Is that an argument to make the change?
<fantasai> TabAtkins: just an editing error
<fantasai> TabAtkins: more general argument that self-{block-start} is what we have here
<fantasai> TabAtkins: other way around could imply you're taking the axis (block) from the container and the direction (start) from the self
<fantasai> RESOLVED: x-self-start and self-block-start are correct, fix the spec