W3C home > Mailing lists > Public > www-style@w3.org > October 2010

@font-face and slow downloading

From: Beth Dakin <bdakin@apple.com>
Date: Mon, 11 Oct 2010 15:14:57 -0700
Message-Id: <93BF7562-1A8B-402C-BB4D-6289F9A046F4@apple.com>
To: www-style@w3.org
Hi all,

Over in WebKit, we have been thinking a lot about the time delay we have with @font-face when the font resource takes a long time to download [1]. It looks like the Mozilla folks have been discussing this recently too [2]. I have searched the www-style list, and I haven't found any former posts about this issue, but I apologize in advance if this has been discussed and decided already. The closest discussion I have found [3] addresses the case where the resource never downloads, but not the case where the download is just taking a while.

The summary is this: Currently, WebKit doesn't display any text until the resource has downloaded, but when a resource takes a really long time to download, the failure to display any text for so long is confusing and a bad user experience. Firefox chooses to display a fallback font right away, and then flashes to the @font-face font once it has finished downloading. This FOUC is not a particularly pleasant user experience either, and based on the activity in the bug, it looks like the Mozilla folks want to tweak it.

The spec addresses what to do in this case somewhat vaguely [4]. Specifically, in Step 4 of the font matching algorithm, the spec says: " Otherwise if the matched font is defined via @font-face and needs to be downloaded, the user agent can either wait until the font is downloaded or render once with substituted font metrics and render again once the font is downloaded." This sentence says that the user agent can choose to layout with one set of *metrics* and then lay out again when the font actually downloads (which is what WebKit does), but it does not actually say anything about substituting an actual *font* in the rendering (which is what Firefox does). And yet, as I described above, neither the current WebKit behavior nor the current Firefox behavior seems optimal.

Since WebKit and Mozilla are both working on this, it would be nice if we could agree on what the best behavior is and put it in the spec. 


[1] https://bugs.webkit.org/show_bug.cgi?id=25207
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=499292
[3] http://lists.w3.org/Archives/Public/www-style/2010Jul/0251.html
[4] http://www.w3.org/TR/css3-webfonts/#font-matching-algorithm
Received on Tuesday, 12 October 2010 06:47:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:39 UTC