- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Tue, 05 Nov 2024 17:52:50 +0000
- To: public-css-archive@w3.org
So the actual processing model then becomes: 1. The presence of a substitution function in a value causes it to be valid at parse time, and left otherwise uninterpreted until substitution time. 2. During substitution, we substitute from the inside out - if substitution functions are nested, the innermost one is processed, then its parent sees those results and gets processed, etc. 3. If, once a subsitution function has had any nested functions replaced, it's now grammatically invalid, it immediately resolves to the guaranteed-invalid value. 4. The guaranteed-invalid value is, in fact, perfectly valid as part of a `<declaration-value>` or similar production, so `var(--foo, var(--does-not-exist))` works correctly if `--foo` exists. 5. We slightly tweak variable processing so that, rather than an invalid variable immediately triggering IACVT directly, the IACVT happens just due to the presence of a guaranteed-invalid value in the property's value causing it to fail to parse correctly. This is also more forwards-compatible. Today, you could write `var(--foo, if(invalid))` and it would be just fine; the `if(invalid)` just looks like some arbitrary uninterpreted content. If we didn't make this change, tho, then when `if()` became recognized as a new substitution function, it would start getting grammar-checked, and cause the whole property to be invalid at parse time. Similarly, if authors are using custom properties today to shuttle around random non-CSS values (for example, JS...) and those values contain something that happens to look like a substitution function (like `if(x < 5) {...}`), without this change that would suddenly switch from being perfectly valid to being invalid at parse time, once `if()` support was added. With this change it'll still be IACVT, so it won't inherit, but it'll at least stick around on the element as a specified value. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11144#issuecomment-2457822881 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:52:51 UTC