- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Tue, 05 Nov 2024 17:36:33 +0000
- To: public-css-archive@w3.org
Another wrinkle here: currently, if a property contains a substitution function, it's always considered valid at parse time (and will be considered *actually* valid or IACVT at computed-value time), *unless* the substitution function itself is grammatically invalid. That's the only way to have a var-containing property actually get considered invalid at parse time. With this change, the concept of "invalid at parse time" becomes harder to reach. Unless we add some even more special behavior (which I'd prefer not to), having a var() in the fallback will cause the outer var() to not be syntax checked until later. That is: ```css .invalid-child { color: var(--foo, var(1)); /* today: invalid at parse time (due to `var(1)`) after change: still invalid at parse time, same reason */ } .invalid-parent { color: var(1, var(--foo)); /* today: invalid at parse time (due to `var(1, ...)`) after change: valid at parse time, IACVT later */ } .unknown-invalid { color: var(var(--foo)); /* today: invalid at parse time after change: valid at parse time, might be valid or IACVT later, depending on --foo value */ } ``` This is a lot more arbitrary than I first thought when I wrote that invalidity requirement. I think we should drop it, and make the presence of a substitution function just always treat the property as valid, regardless of what's inside its parens. This would make all of the above be valid at parse time, then the first two will be IACVT (and the third may or may not be). This would mean that `color: var(1);` would be considered valid at parse time even tho it's clearly going to fail, but I think that's an acceptable tradeoff vs gaining predictability in whether something is parse-invalid or IACVT. This is similar to `color: definitely-invalid 1 2 3 var(--foo);` being valid at parse time and just IACVT, even tho we can theoretically tell that it's impossible for it to be valid even at parse time. This would only be a behavior change for code that's currently invalid; we usually consider this kind of behavior change to be safe to make by default. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11144#issuecomment-2457791524 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 5 November 2024 17:36:34 UTC