[css-fonts-4] Prioritizing font-stretch over font-weight seems wrong

[fantasai]

The font matching algorithm https://drafts.csswg.org/css-fonts-4/#font-style-matching is written in a way that it prioritizes font-stretch over font-weight. For example, if there is a font which has two widths, normal and wide, and only has a bold font for normal, and the author specifies wide bold, we'll get wide rather than bold, and I think we probably want bold rather than wide.

[svgeesus]

Fonts 3 has the same ordering
https://www.w3.org/TR/css-fonts-3/#font-matching-algorithm

[svgeesus]

Relevant test results for font matching section
https://test.csswg.org/harness/results/css-fonts-3_dev/grouped/section/5.2/

These are CSS 2.1 tests. None test the priority of font-stretch over font-weight.

[SergeyMalkin]

We can't read mind of designer about which property is more important. Maybe idea was to give font just a bit more weight, but making font narrow or wide is essential to the design.

Here is my theory of why original CSS authors ordered font properties this way in font matching rules. When UA chooses fonts among sequence of fonts in font-family property, there is less chance to break layout between user machines if you choose fonts of similar widths rather than of different weight. Then, style has higher priority because changing style has more pronounced stylistic difference than weight.

Current WPT tests for css-fonts-4 cover preference of stretch over weight: https://github.com/w3c/web-platform-tests/tree/master/css/css-fonts/matching.
Test for font variations also cover matching priority of font properties: https://github.com/w3c/web-platform-tests/blob/master/css/css-fonts/variations/at-font-face-font-matching.html

[jfkthame]

I realize the spec has always been this way, but it's always seemed less than optimal to me. Ideally, I think neither stretch nor weight should unconditionally take precedence over the other; rather, we'd have a function that defines the "distance" of a given face's (stretch,weight) tuple to the author's requested properties, and choose the "closest" face available in the family.

How best to define such a distance function is of course far from clear, but perhaps it's worth trying?

This could also be an opportunity to revisit the current behavior where a request for font-stretch: 111% in a family that has faces with stretch values of 100%, 110% and 200% will prefer the 200% face, even though it is far more stylistically extreme than what was requested.

[svgeesus]

Removing the Fonts-3 label; any such change once agreed would apply to Fonts-4

[css-meeting-bot]

The Working Group just discussed Prioritizing font-stretch over font-weight seems wrong, and agreed to the following:

• RESOLVED: closed no-change except if the filer wrote a test and UA shows diverging behaviors

The full IRC log of that discussion

<fantasai> Topic: Prioritizing font-stretch over font-weight seems wrong
<fantasai> github: https://github.com//issues/2537
<frremy> fantasai: if you have font-family which "normal + wide" and has a bold for "normal" but not "wide"
<frremy> fantasai: if the author specifies "wide bold" what do you get?
<frremy> fantasai: I think you want "bold"
<frremy> fantasai: right now, we specify "wide"
<frremy> fantasai: I think "bold" is more semantic
<frremy> chris_: we have no test for that
<frremy> chris_: and I don't know if we can change implementations
<frremy> myles: every time I try to change how this selection happens, I get tons of bugs
<frremy> myles: so it might be a good idea, but I don't think this is very doable
<frremy> florian: you can synthetize bold but not font-stretch
<frremy> florian: so it's better to pick "wide" and fake "bold"
<frremy> florian: in the reverse case, we can't fake "wide" so the layout ends up very different
<frremy> RESOLVED: closed no-change except if the filer wrote a test and UA shows diverging behaviors