Re: [csswg-drafts] [css-text-decor-3] Clarify expected computed value for `text-decoration` and similar shorthands (can we omit resolved `currentColor`?) (#12486)

The CSS Working Group just discussed ``[css-text-decor-3] Clarify expected computed value for `text-decoration` and similar shorthands (can we omit resolved `currentColor`?)``, and agreed to the following:

* `RESOLVED: If multiple values are omittable in serialization, but at least one is required, choose the first one in grammar order unless constrained by compat.`
* `RESOLVED: If a <color> value is omittable when computed to currentColor, then it is omittable even though the resolved value is not the 'currentColor' keyword (because colors are absolutized), unless constrained by compat.`

<details><summary>The full IRC log of that discussion</summary>
&lt;ydaniv> fantasai: text-decoration, like background and other shorthands accepts color and other values<br>
&lt;ydaniv> ... when we serialize color we actually return the resolved color, not currentColor<br>
&lt;ydaniv> ... so serializing the currentColor of text-decoration, we actually need to compute and serialize<br>
&lt;ydaniv> ... it's not backward compat and not adding useful information to seralize the color value<br>
&lt;oriol> q+<br>
&lt;ydaniv> ... so we're proposing that text-decoration color is currentColor, which is the initial value, it does not serialize the color just the value<br>
&lt;emilio> q<br>
&lt;emilio> q+<br>
&lt;fantasai> s/the value/the text-decoration-line value/<br>
&lt;ydaniv> oriol: wanted to mention that on another issue I saw similar things, it's other shorthands as well<br>
&lt;ydaniv> ...  would like a more general resolution, that there are minimal possible posibilities we could choose from<br>
&lt;ydaniv> ... so in we do not include color if it's the initial value<br>
&lt;Rossen2> ack oriol<br>
&lt;Rossen2> ack emeyer<br>
&lt;Rossen2> ack emilio<br>
&lt;Rossen2> q?<br>
&lt;ydaniv> emilio: we discussed similar things for shorthands, like margins, where we do want the resolved value<br>
&lt;Rossen2> Zakim, start meeting<br>
&lt;Zakim> inviting RRSAgent<br>
&lt;Zakim> RRSAgent, make logs Public<br>
&lt;Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference<br>
&lt;RRSAgent> logging to https://www.w3.org/2025/07/30-css-irc<br>
&lt;RRSAgent> I have made the request, Zakim<br>
&lt;Rossen2> q?<br>
&lt;ydaniv> ... it's a bit incossitent for length and not color<br>
&lt;ydaniv> ... not super concerned, but a bit wierd<br>
&lt;ydaniv> fantasai: emilio do you have an example?<br>
&lt;ydaniv> emilio: like computedStyle.inset from shorthand, you get the computed and serialize<br>
&lt;oriol> I think emilio is talking about https://github.com/w3c/csswg-drafts/issues/11382<br>
&lt;ydaniv> ...  and in text-decoration it's not the inital value<br>
&lt;ydaniv> fantasai:  2 things here: 1. when there are multiple possibilites, then we &lt;missed><br>
&lt;ydaniv> ... then we keep the first grammar term and skip the others<br>
&lt;ydaniv> ... 2. there are some cases where the initial value, ommitable, is not the resolved value because it's further computed than the actual one<br>
&lt;ydaniv> ...  so do we still omit it? is it still omittable?<br>
&lt;lea> q?<br>
&lt;ydaniv> ... I think for colors it's nicer to omit them, when it's an initial value<br>
&lt;ydaniv> ... I think it makes sense to follow the example oriol mentioned<br>
&lt;ydaniv> ... I think to adopt it as a principle<br>
&lt;ydaniv> ... I think we want to audit it, to make sure we don't make special exceptions<br>
&lt;ydaniv> ... I don't know if following this rule will get us into backward compat issue<br>
&lt;ydaniv> ... for text-decoration we should resolve that, to omit text-decoration-color<br>
&lt;ydaniv> Rossen2: last sentence was clear (:<br>
&lt;fantasai> s/compat issue/compat issue for older shorthands, e.g. background/<br>
&lt;ydaniv> lea: so what is the proposal?<br>
&lt;ydaniv> fantasai: when text-decoration-color is currentColor it's omitted in favour of text-decoration-line<br>
&lt;florian> +1<br>
&lt;ntim> p+<br>
&lt;lea> +1<br>
&lt;ydaniv> lea: assuming it's entirely about the shorthand, and longhand would yield computed?<br>
&lt;ydaniv> fantasai: yes<br>
&lt;ydaniv> lea: would it roundtrip correctly?<br>
&lt;ydaniv> fantasai: &lt;missed><br>
&lt;ydaniv> lea: there are some wierdness around :visited, right?<br>
&lt;ydaniv> fantasai: won't talk about that<br>
&lt;lea> yeah, strong +1<br>
&lt;ydaniv> Rossen2: seeing +1's starting to add up<br>
&lt;fantasai> s/&lt;missed>/it'll round-trip better than with the behavior of serializing out the resolved color/<br>
&lt;oriol> q+<br>
&lt;Rossen2> ack oriol<br>
&lt;fantasai> The case where the behavior differs is if you tweak 'color' in the middle of the round trip<br>
&lt;ntim> (not sure if p+ is right)<br>
&lt;ydaniv> oriol: small point, proposed text, that if t-d-line is set to initial value, but t-d-style is set to value other than initial then it could be -style, right?<br>
&lt;ydaniv> fantasai: correct<br>
&lt;fantasai> This is a good clarification<br>
&lt;ydaniv> Rossen2: can we get a resolution?<br>
&lt;ydaniv> florian: more about the generalization stuff<br>
&lt;ydaniv> ... we should resolve<br>
&lt;ydaniv> Rossen2: any objections?<br>
&lt;ydaniv> florian: there is text, but the generalized one is awkward<br>
&lt;ydaniv> ... in this case it's in grammar order, but do we want to be specific? or generalize?<br>
&lt;ydaniv> fantasai: to make t-d we need to generalize<br>
&lt;ydaniv> ... we need to make sure that it's backwards compat, when there are multiple ones, we pick the first one in the specified order<br>
&lt;ntim> (web compat is relevant here since Safari doesn't ship the proper shorthand so far)<br>
&lt;ydaniv> ...  a computed value of currentColor that is the initial value &lt;missed><br>
&lt;fantasai> PROPOSED: If multiple values are omittable in serialization, but at least one is required, choose the first one in grammar order unless constrained by compat.<br>
&lt;ydaniv> Rossen2: any objections?<br>
&lt;ydaniv> ... hearing non<br>
&lt;ydaniv> s/non/none/<br>
&lt;fantasai> PROPOSED: If a &lt;color> value is omittable when computed to currentColor, then it is omittable even though the resolved value is not the 'currentColor' keyword (because colors are absolutized), unless constrained by compat.<br>
&lt;fantasai> RESOLVED: If multiple values are omittable in serialization, but at least one is required, choose the first one in grammar order unless constrained by compat.<br>
&lt;florian> +1<br>
&lt;ydaniv> Rossen2: anything else on this one?<br>
&lt;ydaniv> ... moving on<br>
&lt;fantasai> RESOLVED: If a &lt;color> value is omittable when computed to currentColor, then it is omittable even though the resolved value is not the 'currentColor' keyword (because colors are absolutized), unless constrained by compat.<br>
</details>


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


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

Received on Wednesday, 30 July 2025 16:32:12 UTC