[css-fonts-4] Computed value for shorthand font: should describe serialization for font-variant-css21 and font-stretch-css3

[drott]

The font shorthand describes the computed value as:

see individual properties

However, the serialization of the computed value for font-variant-css21 and more importantly font-stretch-css3 does not fit under this description. Can we clarify that serialization of a computed style value for the font shorthand fails if the values do not match any of the keyword values described in those two compatibility longhands? And if the values do match those backwards-compatibility longhands then they are serialized as keywords, not as a percentage in the case of font-stretch-css3?

[upsuper]

I believe the "computed value" field there is unrelated to how the computed value is serialized.

Actually, shorthands in general don't have computed value themselves at all. They are split into their subproperties during parsing.

[drott]

Yes. What I suggest to clarify is that a getComputedStyle(someElement).font serialization cannot be produced in case font-stretch contains a value that does not fit any of the keyword values of font-stretch-css3. If it does match one of those keywords in its value, serialize the value of font-stretch as keywords, not as percentages (as which the computed value of font-stretch is to be serialized regularly).

[upsuper]

I don't think there is even consensus whether font should be serialized from getComputedStyle. I don't think Gecko does that. In general, Gecko doesn't serialize shorthands for resolved value at all, except for those which were a longhand.

[litherum]

If getComputedStyle(someElement).font produces a result, it should be round-trippable.

@upsuper We should probably open a separate issue to investigate the general case for what happens if you ask getComputeStyle() for a shorthand (and not discuss it here). I see no reason why the font shorthand should work any differently from any other shorthand.

[drott]

If getComputedStyle(someElement).font produces a result, it should be round-trippable.

Yes, and it would help if cases for when it cannot produce a result would be defined, especially with regards to font-stretch-css3 and font-variant-css21.

[litherum]

It’s defined (for all shorthands) to be empty if any of the subproperties have values that are not accepted by the shorthand.

[drott]

Right, the shorthand only accepts the keywords from font-stretch-css3 but looking at the computed value of font-stretch, it explains it should be serialized to Computed value: | numeric weight value (see description). This is the contradiction I would like to see resolved. What do you think about clarifying the serialization as keyword in the shorthand section?

[litherum]

Oh, you're saying that, if we follow specs as they stand today to the letter, it would be impossible to have a non-empty computed value. Is that right?

[litherum]

Oh, wow, it's really bad that the font-stretch property's computed style says "weight" 😢

[drott]

Oh, you're saying that, if we follow specs as they stand today to the letter, it would be impossible to have a non-empty computed value. Is that right?

Yes, even if it said: numeric stretch value as percentage. We would serialize to a percentage, which would match none of the font-stretch-css3 keywords.

[drott]

Thanks for the update. Are you sure this is as specified instead of something like numeric stretch value as percentage? What about the computed value during an animation?