Define how accentcolor and currentcolor interact

[emilio]

After #5900, we need to define what happens if you do stuff like color: accentcolor; accent-color: currentColor; and such.

[kbabbitt]

We're a bit constrained by the fact that accentcolor and accentcolortext resolve at computed-value time whereas currentcolor doesn't. Sketching out some variations:

a. color: accentcolor; accent-color: currentcolor;
b. color: accentcolortext; accent-color: currentcolor;
c. color: accentcolor; accent-color: currentcolor; border-color: currentcolor;
d. color: accentcolor; accent-color: currentcolor; border-color: accentcolor;

If color were set to some other system color keyword, we'd resolve that to a color at computed-value time, and then we'd be done until we need to resolve currentcolor on some other property at used-value time. I think what makes sense here is to treat accentcolor similarly: resolve it at computed-value time to either the system accent color, or the value of the accent-color property, preserving currentcolor if we find it. If accent-color is or refers to currentcolor, we then apply the rule that the used value of currentcolor on the color property is the used value of color on the parent.

accentcolortext is trickier. We'd need to apply whatever transform the UA uses to turn accentcolor into accentcolortext while still preserving the fact that currentcolor computes to itself. Blink currently does this, which I don't think is expressible in CSS, though maybe it will be once we have inline conditionals and/or custom functions:

  Color accent_color =
      GetAccentColorOrDefault(color_scheme, is_in_web_app_scope);
  // This logic matches AccentColorText in Firefox. If the accent color to draw
  // text on is dark, then use white. If it's light, then use dark.
  return color_utils::GetRelativeLuminance4f(accent_color.toSkColor4f()) <= 128
             ? Color::kWhite
             : Color::kBlack;

For the four cases above, that would give us the following computed values, and I don't think there's any ambiguity about how to resolve further at used-value time:

a. color: currentcolor; accent-color: currentcolor;
b. color: --accent-color-text(currentcolor); accent-color: currentcolor;
c. color: currentcolor; accent-color: currentcolor; border-color: currentcolor;
d. color: currentcolor; accent-color: currentcolor; border-color: accentcolor;

[emilio]

Not sure if quite what you're proposing, sorry if I'm just rephrasing. Something line with what we do for relative font units, would be to resolve "color: accentcolor/accentcolortext" and "accent-color: accentcolor/accentcolortext" relative to the inherited accent-color (and possibly color-scheme?), just like font-size: 2em resolves relative to the font of the parent. Given we definitely need that mechanism for accent-color: accentcolor, that might be simpler?

[kbabbitt]

I think that gives the same result at used-value time, but I don't know whether it would preserve the currentcolor keyword at computed-value time (which my proposal does). Punting on that aspect of it is attractive since we can't currently do it for accentcolortext. But I'd be concerned about it causing web-compat issues if we wanted to revisit it later.