These were recently added to CSS Color 4 – https://github.com/w3c/csswg-drafts/commit/8c1fe16402cee71211530ef5283a0372c8740e7d
- AccentColor = Background of accented user interface controls.
- AccentColorText = Text of accented user interface controls.
There's already a `-webkit-focus-ring-color` exposed, so could be aliased.
Relevant CSS WG Discussions:
Other vendor bugs:
- Blink/Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1338061
- Gecko/Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1775527
Scrap that link to CSSWG issue 5900. Only 7347 is relevant here.
IIRC we don't expose accent colors to prevent fingerprinting, so while this can be implemented with a fixed value, that wouldn't be terribly useful.
Just checked. `-webkit-focus-ring-color` not exposed indeed. Wrongfully assumed info in the WG issue on that was correct, but it was not.
Would there be no way to implement this to be the same colour as `accent-color: auto`, while avoiding fingerprinting?
Again apologies if I've misunderstood but it would seem that `-webkit-focus-ring-color` is exposed.
Based on this quick test:
All three browsers expose an OS accent colour derivative, at least on macOS 12.4.
Tested in Chrome Dev 105, Firefox Stable 102, and Safari 15.5.
While they don't all match each other they're a derivative of the OS colour so cover the fingerprinting front, even if not necessarily the legitimate use case of trying to style your elements to match `accent-color: auto`.
Also the new AccentColor property can be tested in latest Firefox Nightly, and it exposes the accent colour.
Per discussion in https://github.com/w3c/csswg-drafts/issues/7347 this is correct behaviour.