120499 2013-08-29 15:39:54 -0700 Font-faces with different styles should not be mixed in a CSSSegmentedFontFace 2026-03-17 18:39:55 -0700 1 1 1 Unclassified WebKit Layout and Rendering 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED https://jsfiddle.net/pwzcn41h/ BlinkMergeCandidate, InRadar P2 Normal --- 309822 1 rniwa bfulgham ahmad.saleem792 d-r enrica fantasai.bugs hyatt jonlee mitz mmaxfield simon.fraser webkit-bug-importer oldest_to_newest 922703 0 rniwa 2013-08-29 15:39:54 -0700 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. 1315656 1 d-r 2017-06-05 01:53:26 -0700 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. 1315696 2 webkit-bug-importer 2017-06-05 08:59:32 -0700 <rdar://problem/32566994> 1316158 3 mmaxfield 2017-06-06 12:13:43 -0700 You're right, we're not following the spec. 1316440 4 d-r 2017-06-07 04:53:49 -0700 Thanks for taking a look. 1965422 5 ahmad.saleem792 2023-07-06 13:37:10 -0700 Adding test case from Chrome / Blink commit in URL field. 2187633 6 bfulgham 2026-03-05 17:41:39 -0800 Pull request: https://github.com/WebKit/WebKit/pull/60035 2189451 7 ews-feeder 2026-03-12 00:58:23 -0700 Committed 309121@main (d026972d8525): <https://commits.webkit.org/309121@main> Reviewed commits have been landed. Closing PR #60035 and removing active labels. 2191205 8 ews-feeder 2026-03-17 18:39:55 -0700 Committed 305413.507@safari-7624-branch (554415a70bf3): <https://commits.webkit.org/305413.507@safari-7624-branch> Reviewed commits have been landed. Closing PR #4688 and removing active labels.