Re: @font-face and slow downloading

Hi, Beth,

Thank you for starting this thread.
(BTW http://dev.w3.org/csswg/css3-fonts/ is the latest draft.)

We also need to define how font is substituted while remote font
is being downloaded.

In my opinion, substituting it with another remote font doesn't make
much sense. My current thought is summarized in the proposed patch for [1]:

  10         How to choose a fallback font is not specified in the
specification.
  11         Here is how we do it. If a valid local font is listed in the src
  12         descriptor of the @font-face rule, use it as the fallback. If
not, use
  13         the next font face.
  14
  15         Example:
  16         <style>
  17         @font-face {
  18             font-family: samplefont;
  19             src: url([URL]), local([LocalFont]);
  20         }
  21         </style>
  22         <span style="font-family: samplefont, [OtherFont]">Hello</span>
  23
  24         If [LocalFont] is a valid local font, it is used as the
fallback.
  25         Otherwise, [OtherFont] is used.

This is not spec-perfect, but I hope you get the point.

Yuzo

On Tue, Oct 12, 2010 at 7:14 AM, Beth Dakin <bdakin@apple.com> wrote:

> 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.

> Thanks,
> Beth

> [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