Will var(foo) always resolve to the value of the _foo_ property if anything at all?
That is, currently _foo_ is limited to a <dashed-ident> for custom properties, so always has a prefix of a double hyphen-minus --, but if var() was ever specified to accept other values then those would be the normal properties defined by CSS modules and never anything else.
~~ css~
bar
{
--color: orange;
color: green;
background-color: var(color, red); /* similar to currentcolor */
}
~
var(background-color) would basically solve #5292.var(font-size) would be almost the same as 1em.var(line-height) would be almost the same as 1lh. #3257Very interesting idea. 馃 Can you provide any more use-cases to help me grok the usefulness? Since you shared alternative ways to accomplish the same without var, I'm wondering if perhaps this is an ease-of-use concept or if there's ways to use this that fill functionality gaps.
I'm not really proposing to add this, but was just asking for clarification if this would be the only feasible meaning such var() references could ever have.
The main benefit would be with numerical values:
.class {
width: 10px;
height: calc(var(width) + 5em);
}
(I think this adds too much complexity to be worth doing, but I'll play anyway):
Is there a benefit vs. just using custom props? E.g.
.class {
--width: 10px;
width: var(--width);
height: calc(var(--width) + 5em);
}
That would indeed be the only feasible meaning, yes.
This is explicitly off the table, however, because var-substitution has to know the full graph of variable dependencies to detect cycles. Normal properties can gain dependencies on each other in sometimes-nonobvious ways, making it hard to specify and potentially confusing to use; we also add new dependencies over time, which would break code currently relying on there not being such a dependency between two given properties. Custom properties, since they have no meaning whatsoever, don't suffer from either of these problems.
Most helpful comment
That would indeed be the only feasible meaning, yes.
This is explicitly off the table, however, because var-substitution has to know the full graph of variable dependencies to detect cycles. Normal properties can gain dependencies on each other in sometimes-nonobvious ways, making it hard to specify and potentially confusing to use; we also add new dependencies over time, which would break code currently relying on there not being such a dependency between two given properties. Custom properties, since they have no meaning whatsoever, don't suffer from either of these problems.