Re: [csswg-drafts] [css-color-adjust-1] Forced Colors Mode support for gap decorations (#11857)

The CSS Working Group just discussed `[css-color-adjust-1] Forced Colors Mode support for gap decorations`, and agreed to the following:

* ``RESOLVED: add `rule-color` to and remove `column-rule-color` from the list in the forced colors spec``
* `RESOLVED: add explicit text to the forced colors spec to make it clear sshorthands also apply to their longhands`
* `RESOLVED: put the list of affected properties in a note saying at the time of note-writing, here were the affected properties`

<details><summary>The full IRC log of that discussion</summary>
&lt;emeyer> alisonmaher: The gap decorations spec define rule color, which is a shorthand, so the proposal is to add row-rule-color and rule-color to the forced colors spec<br>
&lt;fantasai> +1<br>
&lt;astearns> +1<br>
&lt;kbabbitt> +1<br>
&lt;emeyer> astearns: Any concerns?<br>
&lt;astearns> ack dbaron<br>
&lt;emeyer> dbaron: Minor nit, but the forced color spec looks a little inconsistent about listing short- or longhand properties<br>
&lt;emeyer> …Should probably be consistent about that<br>
&lt;emeyer> …The concept of what you’re proposing is fine<br>
&lt;emeyer> fantasai: The forced colors spec says to use the shorthand if there’s only a shorthand<br>
&lt;emeyer> s/only//<br>
&lt;emeyer> TabAtkins: We could be editorial and say “the longhands of blah blah blah”<br>
&lt;emeyer> fantasai: The real problem of the spec is that it lists properties, and it should be clear that the list isn’t exclusive, because other specs add properties all the time<br>
&lt;emeyer> alisonmaher: So just update to rule-color, then<br>
&lt;emeyer> dbaron: I think the editor of the spec can read it closely, but from a quick read it looks inconsistent<br>
&lt;dbaron> https://drafts.csswg.org/css-color-adjust-1/#forced-colors-properties<br>
&lt;emeyer> fantasai: I don’t see it as inconsistent<br>
&lt;emeyer> dbaron: Maybe it’ll all end up being shorthands<br>
&lt;emeyer> astearns: First thing is, add appropriate shorthand to the list to fix this issue<br>
&lt;emeyer> …Thus, resolution is to add `rule-color` to the list in the forced colors spec<br>
&lt;emeyer> kbabbitt: And delete `column-rule-color` since it’s covered<br>
&lt;emeyer> astearns: Hearing no objections…<br>
&lt;emeyer> RESOLVED: add `rule-color` to and remove `column-rule-color` from the list in the forced colors spec<br>
&lt;emeyer> astearns: I agree with Elika that listing shorthand is sufficient, but I agree with David that it’s not necessarily clear to people not used to specs<br>
&lt;fantasai> I would argue that it's clearer to people not used to specs than to people used to specs :)<br>
&lt;emeyer> …So I’d like to explicitly call out in the relevant sectoin that shorthands apply to all encapsulated longhands<br>
&lt;emeyer> s/sectoin/section/<br>
&lt;emeyer> …So I’d like to take an explicit resolution to that effect<br>
&lt;dbaron> That might depend whether people are more familiar with the shorthands or the longhands, which might in turn depend on whether the shorthands or longhands are older.<br>
&lt;emeyer> (no objections)<br>
&lt;emeyer> RESOLVED: add explicit text to the forced colors spec to make it clear sshorthands also apply to their longhands<br>
&lt;emeyer> s/sshorthands/shorthands/<br>
&lt;kbabbitt> q+<br>
&lt;emeyer> astearns: There should be an explicit criteria in the spec that says why these properties are in the list, so we know that new color propoerties should go onto the list<br>
&lt;emeyer> fantasai: Do we need a list?<br>
&lt;emeyer> TabAtkins: Yes, we need a list<br>
&lt;emeyer> alisonmaher: There is an additional list that has box-shadow and other things<br>
&lt;emeyer> …The main list is all colors<br>
&lt;emeyer> …For the main list, we might be able to do something to make that more clear<br>
&lt;emeyer> astearns: Actually, never mind; what’s in the spec seems good for this<br>
&lt;emeyer> …I thus drop my third proposal<br>
&lt;emeyer> kbabbitt: I was going to ask Elika’s question about whether we need a list<br>
&lt;emeyer> …I guess we can say any color component of a property is force-adjusted; for example, these properties<br>
&lt;emeyer> fantasai: Unless otherwise called out<br>
&lt;emeyer> kbabbitt: Yes<br>
&lt;kbabbitt> ack kbabbitt<br>
&lt;emeyer> astearns: Do you feel strongly about omitting the list<br>
&lt;emeyer> fantasai: I feel it would be better for maintenance going forward to not have an explicit list<br>
&lt;emeyer> …I wouldn’t mind having a list in a note that’s noted as examples<br>
&lt;bkardell> that seems sensible to me<br>
&lt;bkardell> +1 to fantasai's comment<br>
&lt;emeyer> kbabbitt: I do agree that we shouldn’t have to update this spec every time a color property is added<br>
&lt;emeyer> florian: It makes sense having the general principle<br>
&lt;emeyer> …Otherwise, if the list is normative, that’s a maintenance burden<br>
&lt;emeyer> alisonmaher: Question on that note; in the list we don’t have some colors, but they’re in a second list as exceptions<br>
&lt;emeyer> florian: Color-related properties not affected, or affected in a special way; those should be in a normative list<br>
&lt;emeyer> alisonmaher: Sounds good<br>
&lt;emeyer> astearns: I think the proposed resolution is to take the list of affected properties and put them in a note saying, at the time of note-writing, here are the affected properties<br>
&lt;emeyer> Objections?<br>
&lt;emeyer> (silence)<br>
&lt;emeyer> RESOLVED: put the list of affected properties in a note saying at the time of note-writing, here were the affected properties<br>
</details>


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


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

Received on Thursday, 3 April 2025 13:47:52 UTC