- From: François REMY via GitHub <sysbot+gh@w3.org>
- Date: Tue, 02 Mar 2021 21:32:25 +0000
- To: public-css-archive@w3.org
I still don't understand the proposed fallback strategy. ``` --my-color: color(--my-profile, ...); color: var(--my-color, rgb(...)); ``` means that I have to duplicate the rgb value every time I use the --my-color variable, which defeats the purpose of using variables in the first place. Plus, this doesn't work. Variables by default are token streams, so it does not matter that the color() does not yield something valid, as long as it is valid css, it will not cause an error until after it has been replaced in the color property, which means that instead you get `color` that errors at computed time, which makes the color property inherit, which is not what the author want. A solution to this would be to type the custom property such that its value must be converted to a color first, but this requires yet another declaration. One last point is that we also planned to use the fallback in forced-colors mode so that you could do `color(..., ButtonText)` and all color spaces are deactivated in forced color mode. Now, I guess we can do this another way, but this was a convenient system. -- GitHub Notification of comment by FremyCompany Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5931#issuecomment-789231324 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 2 March 2021 21:32:27 UTC