[css-color-adjust-1] Forced Colors Mode support for gap decorations

[alisonmaher]

The CSS Gap Decoration spec defines the following color-based CSS properties:

1. column-rule-color
2. row-rule-color
3. rule-color (which is a shorthand for the first two)

column-rule-color is already noted as being handled by Forced Colors Mode, so the proposal would be to add row-rule-color and rule-color to the list of properties affected by Forced Colors Mode, as well.

CC @kbabbitt

[svgeesus]

That seems like an obvious and correct change.

[css-meeting-bot]

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

The full IRC log of that discussion

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