[css-color-4] Clarify how to resolve `<system-color>` and `<deprecated-color>`

[cdoublev]

To maintain legibility, the <system-color> keywords also respond to light mode or dark mode changes.

This statement is not backed by any defined requirement. I think it should rather be a recommendation for the UAs:

To maintain legicility, the UA should adapt the resolved value of <system-color> keywords to light mode or dark mode changes.

But light mode or dark mode changes seems restrictive. I think UAs should adapt to the used color scheme instead.

[cdoublev]

To elaborate on my previous comment (after a more in-depth research).

To maintain legibility, the <system-color> keywords also respond to light mode or dark mode changes.

This statement is not backed by any defined requirement.

This comment confirms that this requirement needs to be defined (emphasize added):

There may be some updates needed around color-scheme, as well. (i.e. to clarify that it affects the computed value of system colors)

It was written before the resolution to use the corresponding <system-color> value in its colorspace as the computed value, instead of the specified keyword.

However, I would expect it to be clarified in § 14.5. Resolving other colors (CSS Color), which currently only says this:

The declared value for each <system-color> keyword and <deprecated-color> keyword is itself. The computed value is the corresponding color in its color space.

Similarly, I was not expecting to find the <system-color> mappings in CSS Color Adjustment, fwiw.

---

These comments also suggest that how to compute <deprecated-color> is also currently underspecified:

Dropping a note here to say: don't forget to say how these values compute, if they compute to other keyword values or to a fixed color or to themselves. (I'm guessing fewer keywords that compute to themselves here is better for implementations.)

Given that these are legacy values for legacy compat & we don't want authors using them in new content, we can probably safely define them all as light mode values.

And #13459 asked if <deprecated-color>s should be (parse time) aliases of <system-color>s.

---

But light mode or dark mode changes seems restrictive.

I thought other modes than light/dark modes exist tbh. But my point was also that the linked algorithm does not just consider the user preferred color scheme.

[svgeesus]

Better?

[cdoublev]

I think so. Thank you.

Regarding <deprecated-color>. I do not think its computed value is tested on WPT. If it was defined as a parse time alias of <system-color>, as suggested in #13459, this would change the declared/resolved value that can be observed in Chrome and Firefox today: (edit) No, sorry. There was an oversight in my test code. I can observe that the computed value of <deprecated-color> is the same value as the corresponding <system-color>, so defining <deprecated-color> as an alias would only change the declared value :

const { style: declared } = target
const resolved = getComputedStyle(target)

// ButtonBorder (<deprecated-color>) maps to ActiveBorder (<system-color>)

declared.colorScheme = 'light'
declared.color = 'buttonborder'
resolved.color // "rgb(0, 0, 0)"
declared.colorScheme = 'dark'
resolved.color // "rgb(255, 255, 255)"

declared.colorScheme = 'light'
declared.color = 'activeborder'
resolved.color // "rgb(0, 0, 0)"
declared.colorScheme = 'dark'
resolved.color // "rgb(255, 255, 255)"

This is the behavior suggested in the comment I already quoted in my previous comment:

Given that these are legacy values for legacy compat & we don't want authors using them in new content, we can probably safely define them all as light mode values

So do you want to postpone this question until #13459 is answered? Do you want me to open a separate issue? Or do you want to clarify it right away?

[svgeesus]

I agree this needs to be tested on WPT.

I prefer to use an explicit alias, and just discussed this with @Loirooriol but other implementers have yet to chime in.

Not sure this needs a separate issue.