- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Fri, 10 May 2024 13:59:38 +0000
- To: public-css-archive@w3.org
I actually ran into a use case today where this would not just be syntactic sugar, but a substantive improvement. In a web component, I have a user-provided `--color-space` variable and want to interpolate a gradient in that space IFF that is supported (both gradient interpolation in a color space AND that particular color space) or fallback to `oklab` if that space is not supported, or fall back to no `in <colorspace>` token if interpolation in a specific color space is not supported at all. I can do the latter using `@supports` but not the former, since I cannot use `@supports` with CSS variables (can't remember if it reads from root or doesn't support them at all, but neither is helpful here). ---- I’ve also been thinking, instead of the weird "function that can only be used for a property’s whole value" restriction, perhaps it would make more sense to be able to use CSS's regular fallback mechanism by being able to "mark" certain declarations as "don't drop these, I might need them as fallbacks"? More heavyweight to implement, but potentially better DX. There have also been some thoughts about an @-rule that does this in the `@nest` (nee `@group`) discussions. Or, if we keep it as a function, perhaps we can relax the restriction to "only one of these per declaration"? So that one could do things like: ```css background: linear-gradient(to right first-supported(in var(--color-space), in oklab, ), var(--color-stops)); ``` -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5055#issuecomment-2104662746 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 10 May 2024 13:59:39 UTC