Repository navigation
[css-color-adjust-1] Forced Colors Mode support for gap decorations #11857
Description
The CSS Gap Decoration spec defines the following color-based CSS properties:
column-rule-colorrow-rule-colorrule-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
Activity
svgeesus commentedon Mar 6, 2025
That seems like an obvious and correct change.
css-meeting-bot commentedon Apr 3, 2025
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 specRESOLVED: add explicit text to the forced colors spec to make it clear sshorthands also apply to their longhandsRESOLVED: put the list of affected properties in a note saying at the time of note-writing, here were the affected propertiesThe 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
tabatkins commentedon May 6, 2025
(Apologies for having had to miss this meeting, and not seeing the resolutions until now.)
I don't understand the third resolution. Forced Colors Mode has obvious, author-visible effects on the properties it affects. This set of properties needs to be interoperable between browsers; thus, it needs to be specified in some way. We do not currently have a definition anywhere else of what "color properties" are that we can lean on. This means that moving the existing list to a note just... removes necessary normative text.
We do that "list in a note" thing when it's helpful to list out a category that is defined elsewhere (especially when it's diffused, like each property defines itself as being in the category or not). But in this case the list is the canonical definition.
We can add a note about the listed set being something that will grow over time, and thus possibly not being complete at any given time, but the goal should be to keep it complete. Regardless, the current list is a required bit of normative definition, so I object to the resolution as it stands.
svgeesus commentedon May 6, 2025
I agree, and found that resolution to be odd. (The PR puts this in a note, in accordance with the WG resolution)
kbabbitt commentedon May 6, 2025
As I recall, part of the discussion was: Instead of the normative part being a list that would need ongoing maintenance, state that all
<color>components of properties must be adjusted when Forced Colors Mode is enabled unless indicated otherwise. That part was, admittedly, not captured in the resolution.(If there's a reason we really do need a list, then I'd be fine with that - just trying to complete the picture behind that resolution.)
tabatkins commentedon May 6, 2025
Okay, if that's the intended resolution, I think that's reasonable. The PR in #12166 doesn't quite hit that, then, and needs some adjustment.
alisonmaher commentedon May 6, 2025
Yeah I was assuming that "color properties" had more of an implication about its meaning than I guess it does, so I'll update the PR to more clearly specify that these apply to all
<color>components of properties so that the normative text is clearer (but also happy to update what is included in the note and what isn't if it ends up making more sense).