[css-anchor-position-1] Can we clarify the `inset-area` syntax? It can be confusing to read and reason about.

[mirisuzanne]

Overall, I really like the mental model behind the inset-area property, as a quick way to set relative insets. But looking at the syntax today with @una, there were a few aspects of the syntax that make it hard to read and reason about. In my mind the primary issue is the overlap between:

• two axis values, which can be listed in either order
• two values within an axis for spanning multiple areas
• for center and the logical values, names are the same on either axis
• for single values, the implied axis is all

That leads to some interesting situations:

• simple center value becomes center / all rather than center / center
• center / all is not clear unless you know which axis comes first by default (but not always)
• left / center and center / left mean the same thing, but start / center and center / start are different
• bottom center is not the center of the bottom area, that's bottom / center (or center / bottom etc)

There's two changes that I think would help, while leaving some flexibility:

• Clarify spans with a function syntax (span(left, center)). This would reduce the top-level space to two values without needing the / divider. (It might also be useful for grid to support a span() function for spanning multiple grid areas.)
• I expected single axis-ambiguous values to duplicate for the cross-axis: so that the bare keywords start, end, center, self-start, and self-end resolve to eg start / start and center / center etc. (clarification: This helps with the issue where e.g. center first can mean either axis, but center alone always means one specific axis.)

Thoughts?

[una]

+1, as @mirisuzanne mentioned, I started exploring inset-area positioning and found the syntax very confusing thus far, especially with a single value converting to / all and not doubling, as well as the order being interchangable.

[fantasai]

I think we should try to go for consistency with <position> in some fashion (recognizing that this is a separate problem with its own syntax space but still).

[tabatkins]

All right, Elika and I discussed this today, and agree the syntax can be improved a bit.

First, to let us remove the slash (getting closer to <position>, as Elika just suggested), we have two possible syntax suggestions:

<inset-area-alpha> = [
  [ left | center | right | center-left | center-right
  | x-start | x-end | center-x-start | center-x-end 
  | x-self-start | x-self-end | center-x-self-start | center-x-self-end 
  | all ]
  &&
  [ top | center | bottom | center-top | center-bottom
  | y-start | y-end | center-y-start | center-y-end
  | y-self-start | y-self-end | center-y-self-start | center-y-self-end 
  | all ]
|
  [ block-start | center | block-end | center-block-start | center-block-end
  | self-block-start | self-block-end | center-self-block-start | center-self-block-end 
  | all ]
  &&
  [ inline-start | center | inline-end | center-inline-start | center-inline-end ]
  | self-inline-start | self-inline-end | center-self-inline-start | center-self-inline-end 
  | all ]
|
  [ start | center | end | center-start | center-end | all ]{1, 2}
|
  [ self-start | center | self-end | center-self-start | center-self-end | all ]{1, 2}
]

<inset-area-beta> = [
  [ left | center | right | span( left || center || right )
  | x-start | x-end | span( x-start || center || x-end )
  | x-self-start | x-self-end | span( x-self-start || center || x-self-end )
  | all ]
  &&
  [ top | center | bottom | span( top || center || bottom )
  | y-start | y-end | span( y-start || center || y-end )
  | y-self-start | y-self-end | span( y-self-start || center || y-self-end )
  | all ]
|
  [ block-start | center | block-end | span( block-start || center || block-end )
  | self-block-start | self-block-end | span( self-block-start || center || self-block-end )
  | all ]
&&
  [ inline-start | center | inline-end | span( inline-start || center || inline-end )
  | self-inline-start | self-inline-end | span( self-inline-start || center || self-inline-end)
  | all ]
|
  [ start | center | end | span( start || center || end ) | all ]{1, 2}
|
  [ self-start | center | self-end | span( self-start || center || self-end ) | all ]{1,2}
]

In alpha, we just specify the two-region values with a dashed center-* keyword, so if you want to fill the left and center columns, you write center-left.

In beta, we have the span() function, which takes two keywords and spans between them, so you'd instead right span(left center).
(The grammar is a little loose above, for readability; it would actually need to be span( [left && [center | right]] | [right && [center | left]] ), to guarantee two keywords get specified.)

In either case, the 2-track values are now single components, so we no longer need the slash. To fill just the upper-left and upper-center regions, you could say center-left top or top center-left (or equivalently, span(left center) top, for beta).

We think we mildly prefer the dashed version over the span() version, but will leave the choice up to the WG.

---

For the "single-value is a little confusing", we agree, and think Miriam's suggestion is reasonable. So:

Single keyword defaults other axis to:
* duplication if keyword is axis-ambiguous (start/self-start/center/end/self-end)
* all in all other cases

And then we'd probably want to sync this with <position>. Currently, we just disallow saying start by itself (you must specify two keywords if they're axis-ambiguous), but we think it would be reasonable to adopt a similar "duplicate if axis-ambiguous, center otherwise" rule, so background-position: start would be equivalent to start start.

Note that this doesn't solve Mia's bullet point of

center / all is not clear unless you know which axis comes first by default (but not always)

But that's an issue with all axis-ambiguous syntaxes. Learning that the order is always block->inline will continue to be correct across CSS.

[tabatkins]

Una's three examples would thus be bottom, center-bottom, and bottom center

[fantasai]

But that's an issue with all axis-ambiguous syntaxes. Learning that the order is always block->inline will continue to be correct across CSS.

But in the proposed syntax above, in sync with <position>, we introduced the axis-specific keywords (block-*/inline-*) so that you don't have to remember the order.

[mirisuzanne]

I like this solution, and also lean towards the alpha hyphenated approach.

I agree the axis-ordering can be learned. My main concern was the stacking of those implicit rules – with an ambiguous keyword treated as a positional axis keyword when the position is already somewhat ambiguous. This change removes the stacking of ambiguities. :)

[tabatkins]

Okay, inset-area-alpha committed. ^_^

[tidoust]

@tabatkins The new syntax is imbalanced because the closing bracket at the end of line 400 is already closed at the end of line 398:

csswg-drafts/css-anchor-position-1/Overview.bs

Lines 398 to 400 in 7875737

	[ inline-start | center | inline-end | center-inline-start | center-inline-end ]
	| self-inline-start | self-inline-end | center-self-inline-start | center-self-inline-end
	| all ]

Not sure where the closing bracket needs to go, I let you sort that out ;)

Also, the Value Definition Syntax does not mention the possibility of whitespaces being used in multipliers, and at least the CSSTree parser chokes on those at the end of lines 402 and 404.

csswg-drafts/css-anchor-position-1/Overview.bs

Line 402 in 7875737

[ start | center | end | center-start | center-end | all ]{1, 2}

csswg-drafts/css-anchor-position-1/Overview.bs

Line 404 in 7875737

[ self-start | center | self-end | center-self-start | center-self-end | all ]{1, 2}

Could the whitespaces be dropped as well, or should CSS parsers support these whitespaces?

[tabatkins]

Fixed the brackets. I also removed the whitespace from the multipliers, tho I think the parser should be forgiving of that. ^_^

[una]