- From: Kevin Babbitt via GitHub <sysbot+gh@w3.org>
- Date: Sat, 28 Sep 2024 17:33:43 +0000
- To: public-css-archive@w3.org
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