- From: Alexander Kyereboah via GitHub <noreply@w3.org>
- Date: Wed, 17 Dec 2025 17:50:13 +0000
- To: public-css-archive@w3.org
@emilio Yes, right now styling with that substitution would just render the fallback color. I don't think that's exactly the behavior we want either... we would need a lot more complexity to be able to still render the actual system accent color since we're falling back once the value is computed for the variable right now. Here is the prototype: https://chromium-review.googlesource.com/c/chromium/src/+/7098818 I am still supportive of Lea's initial opinion expressing that this is a lot of complexity for a fingerprinting vector that varies in severity per UA. I think leaving the mitigation up to the UA or having gating behind installed apps isn't too out of the question considering we already have the following MAY resolution as a per UA case in the CSS color spec. > User agents may, to mitigate privacy and security risks such as fingerprinting, elect to return fixed values for the used value of system colors which do not reflect customisation or theming choices made by the user. Although I do recognize at least for installed app gating the concern was with differing scopes of availability between `accent-color: auto` and `AccentColor` rather than if it was a sufficient level of mitigation. -- GitHub Notification of comment by kyerebo Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10372#issuecomment-3666494472 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 17 December 2025 17:50:14 UTC