Skip to content

[css-backgrounds-4] Extend position-three to include logical/physical keywords#13954

Open
keithamus wants to merge 1 commit into
w3c:mainfrom
keithamus:css-backgrounds-4-extend-position-three-to-include-logical-physical-keywords
Open

[css-backgrounds-4] Extend position-three to include logical/physical keywords#13954
keithamus wants to merge 1 commit into
w3c:mainfrom
keithamus:css-backgrounds-4-extend-position-three-to-include-logical-physical-keywords

Conversation

@keithamus

Copy link
Copy Markdown
Member

<bg-position> in css-backgrounds-4 is defined as:

<bg-position> = <position> | <position-three>
<<position-three>> = [
  [ left | center | right ] && [ [ top | bottom ] <<length-percentage>> ]
|
  [ [ left | right ] <<length-percentage>> ] && [ top | center | bottom ]
]

<position> (from css-values-5) already includes logical keywords (x-start, x-end, y-start, y-end, block-start, block-end, inline-start, inline-end, start, end). Meaning one can write:

background-position: x-start top;
background-position: x-start 10px top 0px;
background-position: inline-start 10px;
background-position: inline-start 10px center 0px;
background-position: block-end center;
background-position: block-end 20px center 0px;

However <position-three> is physical-only. Is this an intentional omission? This means one cannot elide the length, even when it's the same value, for example all of these are currently invalid:

background-position: x-start 10px center;
background-position: inline-start 10px center;
background-position: block-end 20px center;

And of course these keywords already work in longhand properties properties, so these are valid today:

background-position-x: x-start 10px;
background-position-y: center;

background-position-inline: start 10px;
background-position-block: end;

I think we can update <position-three> to:

<position-three> = [
	[ left | center | right | x-start | x-end ] &&
	[ [ top | bottom | y-start | y-end ] <<length-percentage>> ]
|
	[ [ left | right | x-start | x-end ] <<length-percentage>> ] &&
	[ top | center | bottom | y-start | y-end ]
|
	[ inline-start | center | inline-end ] &&
	[ [ block-start | block-end ] <<length-percentage>> ]
|
	[ [ inline-start | inline-end ] <<length-percentage>> ] &&
	[ block-start | center | block-end ]
]

This allows for a three-value syntax where the "side" specified preceding the <length-percentage> is the effecting side, as it is today.

I was going to file an issue but a PR felt about as much work, so either way we can discuss or close, or if you'd rather see this as an issue then I can also do that.

@keithamus

Copy link
Copy Markdown
Member Author

@LeaVerou @fantasai @SebastianZ - thoughts?

@LeaVerou

LeaVerou commented Jun 2, 2026

Copy link
Copy Markdown
Member

This makes sense to me, and seems like a spec bug. To avoid similar drift in the future, I think <position-three> should be defined alongside <position>, not in a separate spec. Thoughts @fantasai @tabatkins @SebastianZ ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants