Re: [csswg-drafts] [css-color] Mitigating fingerprinting for AccentColor/AccentColorText (#10372)

> > HSV/HSL (BT709/SRGB) is probably sufficient for converting to custom color spaces.
> 
> I don't know what you intend by this. I understand all the individual parts (HSV, HSL, BT709/sRGB and colorspaces) but not what you are tying to convey with them.

LeaVerous mentioned "hue, chroma, lightness" which I understand to be OKLCH. OKLCH is, essentially, it's own colorspace (it's refactoring of BT709 => XYZ => LMS => Custom1 => Gamma 3 => Custom2 => OKLab => Polar-coordinates). Ultimately, we really just need the hue for proper accenting. What the chrominance/saturation and lightness levels are probably not as important. Though I guess there is some utility in knowing how saturated a red they want, though for proper accessibility you ideally want some contrast beyond just grayscale contrast (eg: you don't want pale yellow on bright yellow). That means what the user has selected for their default accent color's saturation/chrominance isn't as important since you'll have to push it into some acceptable level (eg: 1% saturation isn't going to be contrasted enough). Lightness/Value isn't that immediately usable as well. As much as the user may want to have "pink" (low chrominance, high lightness, red hue) as their accent color that's not going to work well in light themes that use white (high lightness doesn't work on light backgrounds). Ultimately it means the only thing that's worth keeping from a user's HSV/LCH is the hue itself.

The point about not needing LCH, and HSV from BT709/SRGB being enough is that it's probably easier for the implementers to not deal with OKLCH support (as great as it is) as a barrier of entry to just feeding the hue that we need. The "Hue" from HSV isn't the same "Hue" from OKLCH, to be clear, but honestly good enough. You can extract that as `1.0` float (0-360 degrees) and decide how to quantize based on how much entropy you want.

> 
> > I don't think it's worth supporting OS's allowing BT2020 accent colors (if that even exists).
> 
> On TVs perhaps they do. More likely, `display-p3` accent colors will probably exist, at least on Apple OS's.

I'm not sure if any of the OS's are using non-SRGB/BT709 color space for accent colors. I'd be surprised if they're using anything other than 8bit SRGB encoded colors. Though if we only care about hue, then it doesn't ultimately matter as much. Saturation is really what dictates what color space it's in. Classically, saturation is distance from Luminance (Y) if in linear, or Luma (Y') if in gamma/SRGB. Granted, that's not perceptual like OKLCH's chrominance, but you can take any RGB color and move it away from D65 and get extra saturation to the point it can become negative and is out of BT709 gamut. That's actually how scRGB works to enables BT2020 support. Or, you can convert that HSV to OKLCH and bump up the chrominance, getting you into BT2020.

Though even if you do OKLCH, there BT709 gamut is roughly below 0.30 Chrominance, and BT2020 is roughly below 0.40. So it supporting past BT709 can get messy. If you do support BT2020, then you will also have to consider how you will do gamut clipping for BT709 users (the majority). I guess for future-proofing you can allow any type of color space for accent color, though that probably makes avoiding fingerprinting even harder if now there's color space for user agents to consider.

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


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

Received on Wednesday, 3 December 2025 23:04:07 UTC