"One predictable pain point with contrast-color() is that it only returns black and white named colors. From a design systems perspective, that's not ideal because you want your colors. You want your harmonious brand and the colors you and your team spent thousands of man hours in meetings deciding on. Those colors. In fact, an earlier version of Safari had color-contrast() (confusing I know, naming is hard) which allowed you to pass in a list of best candidates to choose from. I beleive that proposal got mired in standards discussions, color contrast algorithms, and competing proposals; and contrast-color() is what survived which got simplified down to a binary result."
"One quirky bit needed to make it work is defining a type for --captured-color using CSS @property, a trick I learned from Roma Komarov. To be honest I don't fully understand the why behind Registered Custom Properties and the Computed Value Time Behavior superpower, but my simple brain created a rule "If you're going to compare a variable to a <color> in a CSS if() statement, make sure to register the variable as a <color>.""
contrast-color() currently yields only black or white named colors, which is limiting for design systems that require brand hues. An earlier color-contrast() concept allowed passing candidate colors, but the API simplified to a binary result during standardization. Combining contrast-color() with if() would allow choosing tokens from a color palette once browsers support both features. A current workaround enables experimentation in Chromium, and registering a custom property with CSS @property is necessary when comparing a variable to a <color> inside an if() statement. Future adjustments may be needed for color-query syntax and token selection.
Read at daverupert.com
Unable to calculate read time
Collection
[
|
...
]