[csswg-drafts] [css-color] Resolving color-mix() / color-contrast() (#7302)

emilio has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-color] Resolving color-mix() / color-contrast() ==
https://drafts.csswg.org/css-color-5/#resolving-contrast has some rules to resolve `color-contrast()` values, however I'm not sure they are clear or they match what implementations want or can do.

https://github.com/web-platform-tests/wpt/issues/34158 is an example of this, where it seems like WebKit resolves `color-mix()` at parse-time (they don't seem to support `currentColor` inside `color-mix()`).

In Gecko, I opted for the approach of keeping `color-mix()` in the specified value, but resolve at computed-value time (except for `currentColor` which is special of course, but that's not observable anyways because `currentColor` has ).

It's clear that some amount of these functions needs to be preserved all the way to computed-value time (system colors), or even used-value time, for `currentColor`.

However, it's not clear what amount needs to be preserved at parse-time vs. not. Generally, we preserve stuff at parse-time, (so `element.style.color` would return `color-mix(red, blue)` for example. But then there's the precedent of `calc()` where we normalize generally as much as possible.

I tend to think preserving the function at parse-time is simpler and maybe less confusing for authors, but I don't particularly mind either way.

cc @weining @svgeesus @lilles

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7302 using your GitHub account


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

Received on Monday, 23 May 2022 20:07:10 UTC