Generally, the css-values specification suggest simplification: https://w3c.github.io/csswg-drafts/css-values-4/#calc-simplification

"Simplification" as described there doesn't include clamping, though, does it?

In 8.1.4. Range Checking, we read:

Parse-time range-checking of values is not performed within calc(), and therefore out-of-range values do not cause the declaration to become invalid. However, the value resulting from an expression must be clamped to the range allowed in the target context. Clamping is performed on computed values to the extent possible, and also on used values if computation was unable to sufficiently simplify the expression to allow range-checking. (Clamping is not performed on specified values.)

So I guess the answer depends whether the serialized values of these descriptors are treated like specified or computed (or used) values. I'm not sure what that means in relation to @font-face descriptors (as opposed to CSS properties). Is there a general convention for this, or do we need to specify it in each case?

So I guess the answer depends whether the serialized values of these descriptors are treated like specified or computed (or used) values. I'm not sure what that means in relation to @font-face descriptors (as opposed to CSS properties). Is there a general convention for this, or do we need to specify it in each case?

The test we're pointing out is setting and reading .style.fontStyle. You can't directly set the computed style, so this definitely qualifies as "specified" to me.

"Serialized" vs "computed" concepts don't actually apply to at-rule descriptors, as they're related to the cascade. So yeah, this is indeed underspecified.

I don't have a strong opinion on whether we clamp or not here, but I lean weakly towards "don't clamp" for the same reasons @nt1m gave.

I don't have a strong opinion on whether we clamp or not here, but I lean weakly towards "don't clamp" for the same reasons @nt1m gave.

It seems to me "unclamped" would still leave it undefined whether calc() expressions should be only simplified but left there literally, or evaluated/computed and then left unclamped.

FWIW, leaving things unclamped or having to return csstext as specified literally would prevent the implementation from storing specified values in a more pre-computed, more efficient or canonical way. Instead the implementation would need to keep a backup of the original css text which may not be identical to what it's using internally. The as-specified text/values do not need to be stored, as there is no need to re-compute values after cascading.

I tend to think, keeping only a evaluated and simplified form seems to be the better choice:

• If a descriptor is specified twice, we would already simplify towards returning only one value when accessing the serialized value.
• Similarly, the serialization of @font-palette-values and @font-feature-values is also underspe'ed, which we may want to fix at the same time. In particular in @font-feature-values, there are many examples of how values can be overridden, or redundantly specified (Examples 60 and 61 of https://www.w3.org/TR/css-fonts-4/#font-feature-values-syntax) - Here, it would be very cumbersome to store the original form instead of a canonical form with only the actively used values.
• In issue [css-fonts] Missing serialisation for 0 ranged descriptors inside @font-face #7925 we're discussing the simplification of 0 sized ranges for font-weight, font-stretch, font-style ranges and the proposal to collapse these into a single value seems to have received support there.

For consistency's sake I would prefer the serialization of the descriptors to be the same as the CSS properties, makes it easier (on the WebKit side at least) to implement serialization/parsing without duplicating code or extra code-paths.

How much of a benefit is that, really? The values of the descriptors don't entirely correspond to properties: e.g. the font-weight, -stretch and -style descriptors have an auto value that doesn't exist for the related properties; and they (optionally) take a range, whereas the properties take a single value. (And some property values aren't allowed in the descriptors: bolder, lighter.) So some distinction clearly needs to be made.

I agree with @jfkthame that the grammar of properties and descriptors is related but not identical. And agree with @drott that consensus seems to be forming on simplifying zero-ranged descriptors; but descriptors with a non-zero range have values that the corresponding property does not allow.

So a general rule of simplifying to a canonical form seems clearer.

I added some more to 13.2. Serializing font-related at-rules , explicitly noting the principle of last-defined values and also coalescing blocks.

I made the serialized form be sorted alphabetically, but I am not sure if or where that is specified for descriptor values.

I haven't added anything about simplifying calc expressions, and would like to see a good example.

The CSS Working Group just discussed [css-fonts-4] Unclear serialisation of calc expressions in `@font-face` font-stretch/style/weight descriptors, and agreed to the following:

• RESOLVED: math function simplifcation for descriptors is as if they were specified properties, and descriptors with math functions use the specified-value serialization rules