Re: [csswg-drafts] Define how accentcolor and currentcolor interact (#10971)

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](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/layout/layout_theme.cc;drc=f522344e45882da4c7f7cb1b3a0a7bd747d654bb;l=906), which I don't think is expressible in CSS, though maybe it will be once we have [inline conditionals](https://github.com/w3c/csswg-drafts/issues/10064) and/or [custom functions](https://github.com/w3c/csswg-drafts/issues/9350):

```c++
  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;`


-- 
GitHub Notification of comment by kbabbitt
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10971#issuecomment-2380842978 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Saturday, 28 September 2024 17:33:43 UTC