[css-color-adjust] Used color-scheme should affect the root element color, not initial color

[lilles]

The current spec draft says in chapter 2 that the following must match the users preferred color-scheme:

"the initial color of the background canvas find what we name this in other specs, the initial value of the color property, and the system colors".

For the color property, this does not match what Safari, and Chrome behind a flag, implements. Instead there is a UA rule setting a system color for the root element whose used value depends on the used value of color-scheme. Both implementations have a used value for color:initial of black (as per the css-color spec) regardless of color-scheme.

Proposal: change the spec to say that the color is a system color(?) set on the root element for UA style whose used value is based on the used color-scheme.

[tabatkins]

I'm inclined to still consider this a bug in the current engines - what would be the purpose of making color: initial still produce black in dark-mode? Is there some implementation difficulty in adjusting this value?

Notably, a current weirdness of the styling for our specs has (for some reason) all the index terms styled with an explicit color: initial;, which is causing some minor problems in our attempt to switch to dark mode. If initial adjusted based on color-scheme it would fix that. I suspect many uses of color: initial on the web are the same, and would work better if the initial value adjusted itself.

[tabatkins]

Brought up privately by @lilles: Right now, both Chrome and Safari's actual used value for the root color is a used-time-resolving color (text for Safari, a UA-sheet-only prefixed value for Chrome), so it'll switch between dark and light depending on the color-scheme value in effect for a given element. I think that's what we want the default to be.

I think the resolved value of the various color-taking properties are defined to present the used value, tho, so they'd still be black in gCS() for light-mode. So I'm not sure exactly what our compat constraints are here.

Can we just change the initial value of 'color' to be text?

[AmeliaBR]

Can we just change the initial value of 'color' to be text?

CanvasText, but yes, that sounds like the most sensible solution. Resolved value would be RGB (consistent with resolution in #3847 (comment)), so no observable difference unless using color schemes or using TypedOM to distinguish between computed and resolved.

It could also be consistent with the current behavior in Firefox, which still allows users to set their preferred initial text color (which is used both for the root and for color: initial in general). The user settings could be applied as a customization of the system color scheme.

In contrast, making the initial value of the property be color-scheme dependent seems kind of weird from a cascade perspective.

[css-meeting-bot]

The CSS Working Group just discussed Color-Adjust, and agreed to the following:

• RESOLVED: use "canvastext" as the initial value of color

The full IRC log of that discussion

<fremy> Topic: Color-Adjust
<astearns> github: https://github.com//issues/4608
<tantek> fantasai, my use-case is one I tried to make work but couldn't. I was trying to make the initial letters in a blog post of A-Z that resembled classic wooden building blocks and couldn't :(
<fremy> TabAtkins: the spec says that color-scheme on the root element affects the initial value of the color property
<fremy> TabAtkins: in addition to a couple of other things
<fremy> TabAtkins: the argument is that we should instead change the color of the root in the UA, but not the initial color value
<fremy> TabAtkins: I am not sure why this was proposed, but I see more value in our current spec
<fremy> TabAtkins: because I don't see a value to get black as color when you're in the dark theme
<fremy> TabAtkins: if we changed the initial value, a weird thing I do currently in Bikeshed would work better though
<astearns> ack jfkthame
<fremy> TabAtkins: a detail of this, is that the actual used color in chrome and safari is that it's actually a color that switches its value at computed value time
<fremy> TabAtkins: in safari it's system-color and in blink a custom ua value
<fremy> TabAtkins: and I think that this is a useful behavior
<fremy> TabAtkins: so I tried to find an alternative behavior
<heycam> q+
<fremy> TabAtkins: we say the initial value of color is "text", and "initial" would work as usual
<hober> q?
<fremy> TabAtkins: I think it's ok because all uses of "color" is in property that require to return the used value at getComputedStyle so I'm unsure this would be observable
<tantek> except for scrollbar-color, which has keywords that are returned
<fremy> TabAtkins: but it would be visible in TypedOM
<fremy> TabAtkins: can we get an agreement to match what Safari does in this case?
<astearns> ack fantasai
<Zakim> fantasai, you wanted to ask about SVG
<fremy> fantasai: A question I have is that this could cause issues in SVG, right?
<fremy> TabAtkins: by default, it is, yeah
<fremy> TabAtkins: but I'm not sure what the expectation what would be
<fremy> heycam: it's more common to use black as the default value
<fremy> TabAtkins: and it's mostly relevant for text, for which you usually you would want to switch
<hober> q+
<fremy> emilio: you use currentColor in SVG to get that effect
<fremy> emilio: not the default
<fremy> TabAtkins: the initial value is black, and also fill is black
<fremy> TabAtkins: so that change wouldn't affect anything by default in SVG
<astearns> ack heycam
<fremy> Rossen: if it did break SVG, we would notice and backtrack
<fremy> heycam: if you don't reset the property value, and inherit
<fremy> heycam: does the value switch for the children that inherited that complex value?
<fremy> fantasai: keywords inherit as a keyword, it's gonna be ok
<fremy> heycam: really?
<fremy> fantasai: yes, the keyword is inherited and behave per the element
<astearns> ack hober
<fremy> fantasai: but getComputedStyle returns a resolved value which is a color
<fremy> hober: if the change is compatible with what we already do, and we allow the ua stylesheet to use that paradigm for the color
<emilio> Rossen: so if you animate between `CanvasText` and `Canvas`, for example... How is that supposed to work? Does it become a discrete animation?
<fremy> TabAtkins: I haven't verified that myself
<heycam> q+
<fantasai> s/Rossen:/Rossen,
<fremy> (safari team is checking)
<fremy> emilio: I would like to question the interpolation between keyword values
<fremy> Rossen: you interpolate between the values
<fremy> emilio: but we can't write that value anywhere
<fremy> TabAtkins: I guess right now we cheat
<fremy> TabAtkins: we resolve the keyword, then interpolate, even though we inherit the keyword
<fremy> TabAtkins: just like currentColor since we switched the value
<fremy> emilio: we use some hack to make it work
<fremy> emilio: which relies on a bit to know how to do that
<fremy> emilio: but we don't want to add a bit for each system color
<fremy> TabAtkins: we are going to add interpolate() eventually to fix this
<chris> s/a bit/a hack/
<chris> s/a bit/a hack/
<fremy> hober: the UA stylesheet when the color scheme is built-in sets the color property to the value Text on the root element
<astearns> ack heycam
<fremy> TabAtkins: so what I am proposing is virtually the same as what I am proposing
<fremy> hober: right
<TabAtkins> from hober: WebKit's UA stylesheet sets html { color: text; } if the color scheme feature flag is on
<fantasai> https://www.w3.org/TR/css-color-4/#css-system-colors
<fantasai> System colors that are not deprecated ^
<fremy> heycam: in color-4 we say what to do with the undeprecated values
<TabAtkins> s/as what I am proposing/as what you're currently doing/
<fremy> Rossen: before I formally say yes, let me check
<fremy> fantasai: it's definitely there
<fremy> Rossen: ok then
<fremy> heycam: also for background colors?
<fremy> fantasai: yes
<fremy> Rossen: so we want to resolve on this proposal?
<fremy> astearns: no objection?
<fremy> RESOLVED: use "canvastext" as the initial value of color