- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Jul 2020 23:51:29 +0000
- To: public-css-archive@w3.org
Copied over from #4075: It sounds like what you're wanting is for the guaranteed-invalid value to be preserved as it's substituted thru custom properties, so that the iacvt behavior of making the value unset only triggers on "real" properties (or perhaps on registered custom properties as well), and you can trigger fallback at any point in a variable chain (rather than only at the exact point where the guaranteed-invalid value is introduced). Is this right? This isn't an unreasonable request! In <https://github.com/w3c/css-houdini-drafts/issues/994#issuecomment-663316332> Amelia asks for the ability to explicitly allow a registered property to still assume the guaranteed-invalid value, which is currently only possible when you have a completely unrestricted grammar. Implicitly, this is recognizing that the guaranteed-invalid value actually is "valid" in some circumstances; it's guaranteed to never match the grammar of any predefined CSS property, but it's part of the value space (and thus, matches the grammar) of unregistered custom properties, or registered ones with unrestricted grammar. This is a different choice than what we've currently made in the spec, but it's not a wrong one. And I think I've talked myself into preferring it. It would be a minor behavior change, tho. @andruud, any thoughts? -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5370#issuecomment-666784441 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 30 July 2020 23:51:30 UTC