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

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

2 participants