- From: Lea Verou via GitHub <noreply@w3.org>
- Date: Wed, 09 Jul 2025 16:23:06 +0000
- To: public-css-archive@w3.org
Once #5900 ships I imagine in most cases pages would be setting `accent-color` so it can be used by components etc, so the default value mainly matters as a fallback, so having _something_ is more important than having the actual accent color used. But if we go that route, that should be used everywhere. [At some point](https://github.com/w3c/csswg-drafts/issues/5900#issuecomment-2377710801) WebKit used a weird middle ground that was the worst of all worlds: native form controls used the real accent color, but `AccentColor` was hardcoded to a shade of blue, producing inconsistent results when used alongside native form controls. I see that now they have "fixed" it by always hardcoding accent color to a fixed value ([testcase](https://codepen.io/leaverou/pen/RNWbzBd)). That said, I don't think the fingerprinting surface is significant enough to be worth the complexity being proposed here around hiding the actual value, especially since other UAs do expose the value. How is this significantly different from having `ui-*` font keywords? While we don't expose means to read what the actual font name is for this, pages can read enough information to match it against a list of known system fonts. As an additional data point, I don't know what the Windows UI looks like, but at least in iOS the selection is between 8 presets: <img width="477" height="321" alt="Image" src="https://github.com/user-attachments/assets/1ee734bf-7a36-431e-af46-f012249a75c2" /> If anything, exposing the highlight color introduces more entropy, since that can be custom! -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10372#issuecomment-3053273472 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 9 July 2025 16:23:07 UTC