[css-values] Specs that use CSS values outside of normal style rules should provide information on calc()/non-absolute length resolution in a uniform way

[weinig]

There is an ever growing number of places that use CSS values outside of normal style rules. There are the ones within the umbrella of CSS, such as various at-rules like @font-face, @font-palette-values, etc, and in media query syntax. And there are the ones outside that umbrella, like HTML Canvas, which uses CSS values in a number places such as for declaring colors, fonts and filters, or the Geometry module's rules for parsing a matrix from a string.

Some of these define exactly what to do with calc() and/or non-absolute length values. For instance, CSS Fonts has this to say for @font-palette-values:

Math functions, such as calc(), and also var(), and env(), are valid within descriptor values in 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.

Great stuff. But finding similar rules, even in the same spec for @font-face or @font-feature-values is not something I was able to do.

I would be very helpful if there was some uniformity across specs on how this information was defined.

[svgeesus]

So, should we replicate similar text in a bunch of places, or define it somewhere central and then reference it?

[cdoublev]

Based on this comment, math functions are valid everywhere a <number>/<percentage>/dimension, is accepted. Spec authors should use the corresponding <*-token> variants if they should not be valid.

In practice, UAs do not accept them everywhere a <number>/<percentage>/dimension is accepted, like in the prelude of a keyframe rule.

For arbitrary substitution values like var(), this same comment says they are only valid for property values. Unless otherwise explicitly specified, I guess, like in @font-palette-values declarations.

In practice, UAs accept var() in @page and margin rules, there are discussions to accept env() in the prelude of @media, I think first-valid() could be used in any declaration, etc.

---

Fwiw, I think they should not be explicitly allowed if it is implicitly allowed/disallowed in a central place. This creates confusion, unless they are explicitly allowed where they should be, which might be error-prone.

[weinig]

So, should we replicate similar text in a bunch of places, or define it somewhere central and then reference it?

My thought was to have some default behavior for non-style rule cases, either disallowing relative length units entirely, or using some default values (though what default values you would use for the viewport for cases that might not have access to a viewport, like some of the HTML canvas color parsing functions, is unclear).

(as I forgot to cc the relevant editors originally, doing that now, @tabatkins @fantasai).

[weinig]

To make sure I had issues filed to track them, I filed a bunch of issues on the places I have found so far (at least within CSS):

https://github.com/w3c/csswg-drafts/issues/10876 - [css-fonts] How should relative-length values be interpreted when used in @font-face descriptors? https://github.com/w3c/csswg-drafts/issues/10877 - [css-counter-styles] How should relative-length values be interpreted when used in @counter-style descriptors? https://github.com/w3c/csswg-drafts/issues/10880 - [css-animations] How should relative-length values be interpreted when used in the production in the @keyframes prelude?

as well as this one on whether calc() should be allowed in the @keyframes prelude:

https://github.com/w3c/csswg-drafts/issues/10879 - [css-animation] Is calc() allowed to be used for the production in the @keyframes prelude?

I probably missed some, so let me know if there are any additional ones to track.

[cdoublev]

edit: sorry, this comment was not useful because resolving relative lengths based on computed values is wrong, and the spec is already clear for media queries.

I think they always resolve based on the computed values of the root element but it might be useful to clarify it, especially for nested `@media`. Consequently and to complete your list, it could be clarified for `@import`, which accepts a `` in its prelude.