- From: Viktor Yakubiv via GitHub <noreply@w3.org>
- Date: Thu, 05 Mar 2026 15:48:49 +0000
- To: public-css-archive@w3.org
This is an interesting case. I see two possible ways: 1. resolve light-dark substitution first and then validate against the property grammar 2. consider light-dark a single grammatical chunk, and validate the grammar (first) I conclude, that currently `light-dark()` is designed for the second case: it is part of `<color>`, not a completely separate syntax. In the first case (preferable to me), the following is valid: ```css background: light-dark(transparent, linear-gradient(white, black)); ``` Depending on the color-scheme context, the background shorthand resolves to either `<‘background-color’>` or `<‘background-image’>` inferring from the returned ~syntax~ type by the `light-dark()`. In the second case, the previous is _invalid_ but the following is valid: ```css background: light-dark(linear-gradient(white, whitesmoke), linear-gradient(gray, black)); ``` This second case design enforces `light-dark()` (if go beyond the `<color>`), accept only parameters of the same grammar, i.e. creates a template `light-dark<T>(light: T, dark: T)`. If the first parameter syntax does not match the second parameter syntax, the result is rejected, no matter what. If generalize the `light-dark()` parameters further than `<color> | <image>`, this is an extra condition. I believe, that resulting syntax can be (and better be) checked at the property level. It would then allow cases of sub-type substitution, such as following: ```css --text: oklch(light-dark(0%, 100%) 0 none); color: var(--text); ``` -- GitHub Notification of comment by viktor-yakubiv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12513#issuecomment-4006021611 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 5 March 2026 15:48:49 UTC