- From: Javier Fernandez Garcia-Boente via GitHub <noreply@w3.org>
- Date: Fri, 01 Aug 2025 21:53:13 +0000
- To: public-css-archive@w3.org
javifernandez has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-backgrounds-4] Computed Value serialization of background-position and its longhands == In L4, the ```background-position``` is defined as a shorthand of ```background-position-x``` and ``background-position-y``, but its Computed Value definition remains the same than in L3: https://drafts.csswg.org/css-backgrounds-4/#the-background-position > list, each item a pair of offsets (horizontal and vertical) from the top left origin each given as a computed <length-percentage> value So it seems the computed value it's serialized without the origin keywords. Even more, the ```<bg-position>``` is defined in the as ```<position>|<position-three>'``` and there is a NOTE in the CSS Value 4 spec regarding the ```<position>``` computed value that explicitly states to remove the origin keywords in the serialization. Hewever, the longhands defined in the L4 state that their computed value must be serialized as the **offset plus the origin keyword**: https://drafts.csswg.org/css-backgrounds-4/#background-position-longhands > A list, each item consisting of: an offset given as a computed <length-percentage> value, plus an origin keyword I think the reason why we need the origin in the longhands it's because the logical values ```x-start``` and ```x-end``` added to the syntax in L4, but I'm not sure I understand why we don't need the origin keywords in the shorthand too. I just wanted to be sure this is the intended behavior because there are a [few tests ](https://wpt.fyi/results/css/css-backgrounds/parsing/background-position-computed.html?label=experimental&label=master&aligned )already checking for the absence of the origin keywords in the ```background-position```property. It seems that **only chrome** fails in the case of the ```<position-three``` syntax. It might be due to a bug in Chrome (although not the one registered in wpt.fyi), but I wanted to be sure the origin keywords are not going to be required in the shorthand. Finally, there are also [tests](https://wpt.fyi/results/css/css-backgrounds/parsing/background-position-x-computed.html?label=experimental&label=master&aligned) for the longhands, where it's expected that the computed value **omit** the keyword (eg left -20px expects 20px). So far it fails in Chrome because the longhands x/y lacks support for the _2 values_ syntax ([bug 40468636](https://issues.chromium.org/issues/40468636)), which I'm working on right now, but again I'd need some clarification about the origin keyword in the computed value serialization. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12564 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 1 August 2025 21:53:14 UTC