Repository navigation
[css-fonts] [palettes] Disallow usage of var() in @font-palette-values #6931
Description
In #6631 (comment) @andruud suggests that usage of var() inside @font-palette-values is unconventional compare to the usual usage of var().
We may want to disallow var() usage in @font-palette-values or - if that's not acceptable - specify it differently, so that it's evaluated in the element's context if really needed / possible.
@andruud's feedback:
However, allowing var() would introduce an awkward and unwanted dependency on the computed style of the root element, which we should probably avoid. It also seems a bit unfortunate from an author's standpoint to deviate from the computed-value-time/element-centric nature that var() currently has, and decide that it works in a different way here.
Going in the "author env()" direction seems more approachable, depending on its shape. There are other reasons we may need things like that as well, e.g. #6641.
Spec text after ee8dada:
Functions such as ''calc()'', ''var()'', and ''env()'' are valid within the braces of a
''@font-palette-values'' rule. They are evaluated within the context of the root
element. Relative units are also evaluated within the context of the root element.
Activity
drott commentedon Jan 4, 2022
CC @tabatkins
tabatkins commentedon Feb 4, 2022
Anders points to #6641; in there I say that "author env()" isn't great because it means that, in many cases, you'll be forced to duplicate the same information in both places. Most variables are document-global anyway, so the choice of whether you do it as a var()-on-root or author-defined env() would be mostly arbitrary, and having to decide between the two wouldn't be ideal.
I'm supportive of the idea Anders hit in that thread, of allowing these sorts of non-element cases to use the initial value of custom properties, which are provided by
@property. That satisfies the use-case of "author-level env()" while simultaneously continuing to act as a normal custom property. I think that would be appropriate here as well.LeaVerou commentedon Feb 4, 2022
This keeps coming up. We don't want authors to be duplicating colors in these rules, but also we don't want a dependency on the root element's computed style.
What if we define a new rule (
::document?) where authors can define values for custom properties that are above the root node, i.e. akin to applying to the actual document node. Then media queries and other at rules can usevar()references, and they'd resolve relative to that, and because it's not an element, nothing depends on any element's computed style.tabatkins commentedon Feb 4, 2022
@LeaVerou do you have an objection to the suggestion Anders made, to rely on the initial value of custom props, as defined by
@property? Note that you can nest @Property in MQs and other conditionals if needed, to supply the "right" initial value.LeaVerou commentedon Feb 4, 2022
@tabatkins
I think that's a clumsy solution, as it requires a new
@propertyrule for every single property. Authors tend to define A LOT of properties in their root rules (eg). Even when@propertyis widely supported, I don't see authors using it for every single custom property they define.Certainly better than nothing though!
litherum commentedon Mar 25, 2022
I'm operating under the following constraints:
Beyond satisfying those 2 constraints, I have no opinion how this gets resolved.
tabatkins commentedon Mar 25, 2022
No worries, this is being discussed in #6641 for a general solution.
svgeesus commentedon Sep 1, 2023
So, should we close this issue and use whatever general solution emerges from
yisibl commentedon Oct 10, 2024
This article also expresses a desire to support
var().