Re: [csswg-drafts] [css-variables] Substitution of invalid variables into other variables (#4075)

Hm, looking at your referenced test case in the bug, it seems like a somewhat unrelated issue to this thread.

What you're seeing is just the fact that a property becoming iacvt makes it `unset` (aka `inherit` or `initial`, depending on whether the property inherits or not). In your examples, the child's `--c` property becomes iacvt (because it references another custom property which is iacvt due to using the guaranteed-invalid value), and thus it switches to its inherited value, which is the `red` it gets from the parent element.

> And just as @emilio presented, #4075 (comment) this behavior looks unexpected even on the surface

Emilio's comment doesn't look relevant here, either - he's saying that in his example, the variables behavior doesn't act like "drop invalid properties" (since we can't actually do parse-time dropping). But in your example, it *does* look exactly like dropping an invalid property - if you pretend the child's `--c` is invalid and dropped at parse time, then you'd see exactly the behavior you're getting, where the parent's `--c` declaration inherits down to the child.

------

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/4075#issuecomment-666780121 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:48:24 UTC