Created attachment 98812 [details] Screenshots of the test page in various browsers Webkit based browsers appear not to follow the font matching algorithm defined in the CSS3 Fonts Module working draft. All other browsers that I've tested (including IE 6-8) correctly follow this algorithm. The problem occurs when you define a @font-face font family with fewer weights and styles than you use on the page. The spec says (and the behavior of all other browsers is) that when you have a @font-face family defined, font matching should match the nearest weight and style available in that family. If only one weight/style is available, then that weight/style should be used for all text set in that family on the page. My test case page illustrates this problem and provides more detail: http://seanmcb.com/typekit/webkit-font-matching-bug.html I've attached a screenshot of the rendering of this page in Chrome, Safari, Webkit nightly, IE6, and Firefox 5 so you can compare. Firefox 5 and IE6 show the expected behavior. There are two aspects of this bug that make it a problem: 1. @font-face fonts display differently for certain weights/styles between Webkit browsers and other browsers. Fallbacks should not be used here. 2. When on Mac OSX and the font is installed locally, a local font is used for certain weights/styles even when no local() item is listed in the @font-face's src property. According to the spec, local fonts should never be used when a @font-face exists. Local fonts could have different metrics or otherwise inconsistent rendering with a web font version of the same font.
Forgot to mention that this should be tested two ways: 1. First, open the test page without Arvo installed on your system. This will show you the fallbacks being incorrectly used when every variation should be rendering in the single bold italic variation that's defined in the single @font-face rule. 2. Then download Arvo via the link on the Google Webfonts page and install it on a Mac OSX system. Load the test page again, and you'll see the locally installed fonts being used alongside the web font. According to the spec, this should never happen. (A @font-face rule should override the whole locally installed family unless a local() statement is included in the src property.) Here's the download link for the font: http://www.google.com/webfonts/family?family=Arvo&subset=latin#download
Hi Sean, I try to figure out what is happening here. I did not read all the standard, so perhaps you can help me a bit here. - It seems to me, if the browser (at least Firefox) does not support any font listed in the src property of font-face, it has the same behaviour as WebKit, so you see 4 different lines (font-face is ignored basically). - My second question: your font-face rule contains multiple src properties. It seems both FireFox and WebKit processes only the last one (the others are ignored). Are these two things correct from the viewpoint of the standard? My suspicion is that WebKit simply does not have a built-in support for these fonts, and ignores the font-face. But I need to confirm this.
Dan Bernstein (mitz), David Hyatt: do you remember this patch: http://trac.webkit.org/changeset/34794 In CSSFontSelector::getFontFace, there are these lines: if ((traitsMask & FontStyleNormalMask) && !(candidateTraitsMask & FontStyleNormalMask)) continue; if ((traitsMask & FontVariantNormalMask) && !(candidateTraitsMask & FontVariantNormalMask)) continue; If I specify a font as italic: @font-face { font-family: 'Arvo'; src: url('arvo-bolditalic-webfont.eot'); font-weight: bold; font-style: italic; } And add this to a page: <div style="font-family: Arvo;"> Arvo Text </div> this check fails when traitsMask has FontStyleNormalMask, since it is an italic font. According to the Sean, the engine should not care about it. This works correctly: <div style="font-family: Arvo; font-style: italic;"> Arvo Text </div> What do you think? Shall I add another for loop if no font faces are added, which ignores FontStyle checks? What about the other condition?