[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?

[litherum]

We may need to preserve existing behavior. Today, if you style something with font-stretch: expanded, the computed style of the font-stretch property is expanded (and isn't a number or percentage). This behavior is what WebKit does today. Depending on web compatibility, it may be required.

Also, it shouldn't be necessary to keep a bool around in the implementation to distinguish between expanded and 125%. This means, if you have font-stretch: 125%, it should be legal (but not necessarily required) to report the computed value of the font-stretch property as expanded.

Because the font shorthand only accepts the keywords for font-stretch, its computed value must only contain keywords.

[drott]

I understand the compatibility concerns, but I see some consistency issues as well. What about the case when you animate from say condensed to extra-expanded and query for the computed value during the animation? Would you prefer a situation in which the computed value toggles between percentage and keywords? E.g.: ...123%, 124%, expanded, 126%...

Otherwise I agree on the part where an extra bool should not be necessary to detect the keyword-matching values.

[litherum]

Would you prefer a situation in which the computed value toggles between percentage and keywords?

I think yes, because compatibility is more important than consistency.

[drott]

Just to clarify: How does WebKit serialize the computed style value of font-weight a) in the font: shorthand, b) for the font-weight property: Does it serialize font weight 400 and 700 as normal and bold respectively, or as 400 and 700 numbers?

[litherum]

We will always use keywords if possible.

[fantasai]

Current proposal (in the spec) is to keep the computed value of font-stretch as a percentage, but require percentages matching a keyword to be serialized out as that keyword for the purpose of getComputedStyle(). Agenda+ to discuss that.

(I didn't understand the issue about the small-caps keyword. Afaik, it's still just a keyword?)

[astearns]

@fantasai should this go on the weekly agenda, since we didn't get to it at the F2F meeting?

[atanassov]

@astearns yes, pulling to this week's call

[svgeesus]

@litherum said:

We should probably open a separate issue to investigate the general case for what happens if you ask getComputeStyle() for a shorthand

Agreed, and that is #2529 [cssom] getComputedStyle and shorthands which was recently resolved

[litherum]

I'm happy with @fantasai's suggestion about the computed value of font-stretch being a percentage, but getComputedStyle() returns strings for certain percentage values.

[svgeesus]

computed value: percentage*

*usually

[css-meeting-bot]

The CSS Working Group just discussed Computed value for shorthand font: should describe serialization for font-variant-css21 and font-stretch-css3, and agreed to the following:

• RESOLVED: Have computed value always be a percentage and have serialization always show a percentage. Neither deal with keywords

The full IRC log of that discussion

<dael> Topic: Computed value for shorthand font: should describe serialization for font-variant-css21 and font-stretch-css3
<dael> github: https://github.com//issues/1671#issuecomment-400863224
<dael> myles: There's...the issue here recently has migrated. The thing discussed now is the font-stretch
<dael> myles: In L3 font-stretch took keywords. In L4 they're % number so you can animate. That's for variable fonts.
<dael> myles: Issue is about how the computed style of this property should be a number of % rather then keyword or a number
<dael> myles: If you're trying to animated from condenced to 139% if computed is % o r keyword you can't animate. Solution is always a number and getcomputedstyle function returns strings if the computed style is a magic number we define
<florian> the explanation did make sense
<dael> astearns: Are magic number spec orimpl dependent?
<dael> myles: There's a table
<chris> its the magic numbers that correspond to the keywords
<dael> myles: Not much of an issue, it's do you want to animate from keyword to number. If yes, and I think it's yes, we need backwards compat
<dael> florian: Makes total sense to me
<chris> +1 this seems good to me
<dael> astearns: me too
<dael> emilio: Serialize as number?
<dael> myles: We're discussing now if computed style of font-stretch shoudl b e a number or as specified.
<dael> emilio: Gecko and blink ship as number so web compat not problem.
<dael> myles: Backwards is gCS. If you set font-stretch to a value that used to be a keyword do you get numebr or keyword
<dael> emilio: number
<dael> chris: It's serialization of gCS and I think there's web compat on that
<dael> myles: I guess there isn't much web compat if blink and gecko give number.
<dael> florian: We can start with that and ifthere is web compat revisit
<dael> astearns: Perhaps a note in the draft saying may be web compat with always serialize as number and may need magic conversion at some point.
<dael> florian: Reasonable
<fremy> +1
<dael> astearns: Anyone with evidence that we need magic number to string conversion in gCS?
<dael> astearns: Prop: Have computed value always be a percentage and have serialization always show a percentage. Neither deal with keywords
<dael> astearns: Objections?
<dael> RESOLVED: Have computed value always be a percentage and have serialization always show a percentage. Neither deal with keywords

[drott]

Thanks, I am happy with this resolution.

[svgeesus]

Just checking this is resolved. I see in the spec:

For compatibility with [CSS-FONTS-3], getComputedStyle() serializes values that correspond to one of the font-stretch keywords as that keyword (instead of as a <percentage>).

@litherum are further edits needed or can this be closed?

[svgeesus]

The current text seems at odds with "RESOLVED: Have computed value always be a percentage and have serialization always show a percentage. Neither deal with keywords"

[svgeesus]

This looks to have been resolved, as the current spec text is

{{getComputedStyle()}} always serializes its value as a <<percentage>>, 
regardless of how the value was specified by the author, or whether
 or not a keyword happens to map to the value.