- From: Xidorn Quan via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Nov 2020 13:43:39 +0000
- To: public-css-archive@w3.org
> Same as `color: currentColor`. I believe when the potential for cycles is as limited as this, they can be detected and resolved (see `var()` cycles) The first question would be how cycle should be handled. In `var()`'s case, all properties involved become invalid on computed-value-time. I think the thing is more complicated in color's case. I'd like to remind that `currentcolor` is a computed-value-time keyword, and only gets resolved at used time. If we have multiple colors (as @LeaVerou's proposed syntax indicates), we may want them to behave in the same way. Then we would have to resolve the cycle at used value time, and we create a new concept of invalid value at used value time, and compositor may need to resolve such cycle at 60fps. The reason that it has to happen at used value time is because we want `currentcolor` to be inherited as a keyword, and so probably others as well. Consider we have ```css color: current(caret-color); caret-color: current(text-emphasis-color); text-emphasis-color: current(color); ``` It may be invalid for the current element, but as soon as its descendant specifies one of them, the cycle should be broken, and they should all use that color. Since they have to be inherited as is, we can't resolve the cycle like `var()`s. At the end, I don't understand what value this proposal really adds on top of the ability to customize interpolation of variables especially given its additional complexity. Could anyone explain? -- GitHub Notification of comment by upsuper Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5292#issuecomment-725430498 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 11 November 2020 13:43:41 UTC