Repository navigation
[css-fonts-4] Unclear serialisation of calc expressions in @font-face font-stretch/style/weight descriptors #7964
Description
css/css-fonts/variations/at-font-face-descriptors.html defines various expectations for what should happen with calc() expressions, but does not consistently do that, some are evaluated, some are not.
This issue is spun off of recent WebKit WPT test merge where expectations were changed from evaluated and clamped calc() results to unevaluated calc() results when reading back the descriptor.
WebKit/WebKit@c3e9369
Generally, the css-values specification suggest simplification:
https://w3c.github.io/csswg-drafts/css-values-4/#calc-simplification
We need to define what the serialized value of the font property-descriptors font-weight, font-stretch, font-style in
https://drafts.csswg.org/css-fonts-4/#font-prop-desc should be.
Activity
[-][css-fonts] Unclear serialisation of calc expressions in `@font-face` font-stretch/style/weight descriptors[/-][+][css-fonts-4] Unclear serialisation of calc expressions in `@font-face` font-stretch/style/weight descriptors[/+]Fix at-font-face-descriptors.html to not expect clamped specified val…
jfkthame commentedon Oct 27, 2022
"Simplification" as described there doesn't include clamping, though, does it?
In 8.1.4. Range Checking, we read:
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-facedescriptors (as opposed to CSS properties). Is there a general convention for this, or do we need to specify it in each case?nt1m commentedon Oct 27, 2022
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.tabatkins commentedon Oct 27, 2022
"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.
drott commentedon Oct 28, 2022
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:
@font-palette-valuesand@font-feature-valuesis 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.font-weight,font-stretch,font-styleranges and the proposal to collapse these into a single value seems to have received support there.nt1m commentedon Oct 28, 2022
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.
jfkthame commentedon Oct 28, 2022
How much of a benefit is that, really? The values of the descriptors don't entirely correspond to properties: e.g. the
font-weight,-stretchand-styledescriptors have anautovalue 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.svgeesus commentedon Nov 16, 2022
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.
[css-fonts-4] Seralize `@ffv` with last-defined, #7964
svgeesus commentedon Mar 1, 2023
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.
css-meeting-bot commentedon Apr 19, 2023
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 rulesThe full IRC log of that discussion
<emeyer> TabAtkins: Fundamental issue is that simplification rules for math functions refer to resolution stages<emeyer> …Those don’t apply in descriptors
<emeyer> …So what are the rules for serialization, and do they match?
<emeyer> …Apple wants serialization to be the same as CSS properties, which makes sense
<emeyer> …Not sure if we’re compat-constrained or not
<emeyer> dbaron: The one thought I have is that descriptors seem a lot like specified values
<emeyer> TabAtkins: Agreed
<emeyer> emilio: Agreed
<emeyer> TabAtkins: I think it’s reasonable to say we treat things the same
<emeyer> astearns: We could resolve on that and see if anyone complains
<emeyer> TabAtkins: proposed resolution: math function simplifcation for descriptors as if they were specified properties, and descriptors with math functions use the same serialization rules as properties
<emeyer> RESOLVED: math function simplifcation for descriptors is as if they were specified properties, and descriptors with math functions use the specified-value serialization rules
[css-values-4] Non-property contexts treat math functions as specifie…
[Fonts] Move font-style clamping from parser to computed value time