Re: [csswg-drafts] [css-backgrounds-4] Computed Value serialization of background-position and its longhands (#12564)

The CSS Working Group just discussed `[css-backgrounds-4] Computed Value serialization of background-position and its longhands`.

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> oriol: Here there's a disagreement in the spec about computed value of background-position<br>
&lt;fantasai> oriol: Shorthand says computed value is length-percentage per axis<br>
&lt;ntim> (did we skip https://github.com/w3c/csswg-drafts/issues/9083 ??)<br>
&lt;fantasai> oriol: but longhands it includes also a keyword representing the origin<br>
&lt;fantasai> oriol: We need to decide if the computed value keeps this keyword or not<br>
&lt;fantasai> oriol: One way to observe this is with logical keywords<br>
&lt;fantasai> oriol: e.g. background-position-x: x-end 25%<br>
&lt;TabAtkins> My position on any question of how 'inherit' works for non-inherited properties: that's weird, don't do that.<br>
&lt;fantasai> oriol: If a child inherits this value, does it inherit the x-end 25% as a logical thing, or does it resolve to 75% and then child inherits 75%?<br>
&lt;fantasai> oriol: It's so far only implemented in WebKit, and it resolves the percentage<br>
&lt;TabAtkins> +1 to WebKit behavior here, I think<br>
&lt;fantasai> oriol: However I propose to keep the keyword.<br>
&lt;TabAtkins> (as a knee-jerk response, at least)<br>
&lt;fantasai> oriol: It's not absolutely necessary, but it will help with the logical longhands because we want to keep different meanings depending on whether you use a physical longhand or logical longhand<br>
&lt;fantasai> oriol: So that would be the first part, and the rest would depend on whether we resolve on this or not<br>
&lt;TabAtkins> fantasai: I feel like we need to figure out he resolution of the shorthand/longhands<br>
&lt;TabAtkins> fantasai: is it possible to... computing it thru is simpler, it gives you a more calculated answer<br>
&lt;TabAtkins> fantasai: I don't care about inheritance, no reasonable person does "background: inherit", especially thru direction change<br>
&lt;TabAtkins> fantasai: but if we need it for shorthand/longhand, it's reasonable to keep the keywords around<br>
&lt;TabAtkins> fantasai: but if we don't need it, I think it's preferable to compute the keyword away<br>
&lt;fantasai> oriol: I think it would be good for the logical longhands, but other way to do it could be an internal flag<br>
&lt;fantasai> oriol: but if we have a keyword, then we already know if it's logical or physical<br>
&lt;fantasai> fantasai: hmm, ok, then in that case let's keep it<br>
&lt;fantasai> oriol: So how do we serialize the resolved value? We're compat constrained to not include it in the existing syntax<br>
&lt;fantasai> fantasai: we would need to drop the keyword for physical ones<br>
&lt;fantasai> oriol: I checked for gCS on `right 50%`<br>
&lt;fantasai> oriol: WebKit was (at least until recently) including the keyword<br>
&lt;fantasai> fantasai: might be ok to keep keyword in both cases<br>
&lt;ntim> q+<br>
&lt;fantasai> fantasai: but we do currently hvae interop on resolving to percentage<br>
&lt;ntim> q-<br>
&lt;fantasai> oriol: When WebKit added the new keywords they resolve it to percentage<br>
&lt;ntim> q+<br>
&lt;fantasai> oriol: We could go for ocnsistency and never include keywords<br>
&lt;fantasai> oriol: Or we could include them for logical, or include them always<br>
&lt;astearns> ack ntim<br>
&lt;fantasai> ntim: Was it background-size or background-position that had a special rule for omitting one of the two axises?<br>
&lt;fantasai> ntim: there was a difference in prefixed vs unprefixed behavior<br>
&lt;ntim> it was background-size!! https://github.com/w3c/csswg-drafts/issues/7802<br>
&lt;karlcow> SeeAlso https://github.com/w3c/csswg-drafts/issues/7802 [css-backgrounds] Always serialize 'background-size' and mask-size as two values<br>
&lt;fantasai> fantasai: Maybe we should figure out the logical property cascade and then figure this one<br>
&lt;fantasai> ntim: wpt is consistent, what's the issue?<br>
&lt;fantasai> oriol: The spec contradicts itself<br>
&lt;fantasai> oriol: and we need to decide how to fix it<br>
&lt;fantasai> ntim: If we already have interoperable implementations, that would drive compat<br>
&lt;fantasai> oriol: Also there are new keywords<br>
&lt;fantasai> oriol: Some behaviors are only observable with these<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12564#issuecomment-3525909242 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 13 November 2025 07:06:25 UTC