Consider merging https://chromium.googlesource.com/chromium/blink/+/7823ceba809d5c05bffeeb9e732e92fe76fab7e9 Before this patch, when a glyph for the character to be rendered is not in the matched @font-face, glyph from other @font-face (with different style) in the family or system font with the same name were used as fallback. This behavior does not follow the font matching algorithm (http://www.w3.org/TR/css3-fonts/#font-matching-algorithm): "6. If no matching face exists or the matched face does not contain a glyph for the character to be rendered, the next family name is selected and the previous three steps repeated. Glyphs from other faces in the family are not considered." This patch fixes the issue by changing CSSSegmentedFontFace to represent fonts of single font traits. This also fixes a bug that the browser downloads fonts for unused styles.
Myles, while looking at WebKit's code for variable fonts matching on style, stretch, weight, I came across this again. WebKit nightly r217775 still falls back across the boundaries of the initial style/stretch/weight "narrow-down". "Narrow-down" in the sense of the font matching algorithm, which aims to reduce the set of stretch, style, weight options down to one. 5.2.6 Font Style Matching https://drafts.csswg.org/css-fonts-3/#font-style-matching still says: "If no matching face exists or the matched face does not contain a glyph for the character to be rendered, the next family name is selected and the previous three steps repeated. Glyphs from other faces in the family are not considered. " As far as I understand, the code in https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/css/CSSFontFaceSet.cpp#L431 just sorts the set, instead of narrowing it down to matching only one set of identical traits, so that the list of faces as members of CSSSegmentedFontFace would only differ in unicode-range. https://codepen.io/anon/pen/GEgjyV is a reproduction: FF and Chrome only display the first 'a' in "Great Vibes", whereas WebKit nightly r217775 also shows the 'b' in Great Vibes, which it shouldn't do according to the font matching algorithm, since the @font-face which has unicode-range coverage for 'b' is of a different font-stretch: variant. Could you perhaps comment on this issue? I'd like to find out whether we have the same understanding of the font matching algorithm. Thanks in advance.
<rdar://problem/32566994>
You're right, we're not following the spec.
Thanks for taking a look.
Adding test case from Chrome / Blink commit in URL field.