Re: @font-face and slow downloading

On Oct 20, 2010, at 6:01 AM, Håkon Wium Lie wrote:

> John Daggett wrote:
> 
>>> 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.
>> 
>> Right, I think the question is what the delay should be.  Too long and
>> the viewer doesn't see the text of a page for a slow loading font, too
>> soon and you get a "double pop", white to fallback, then fallback to
>> downloaded.
> 
> There are cases where the webfont will not be downloaded at all. For
> example, on a mobile phone with narrow bandwidth, or if every kB costs
> you money, you may not want to use webfonts. Just like images can be
> turned off in certain browsers.
> 
> Therefore, I don't think the spec should try to define delays or other
> behavior which is dependent on the user's environment. 

Your conclusion seems like a non sequitur to me. If webfont downloading is turned off, then there is no issue at all with delays. The issue is only relevant when the font is going to download. I think it is reasonable for the UA to estimate how long the download will take after, say 1-2 seconds, and if it is going to be much longer than that then paint with a fallback font while it waits.

Received on Wednesday, 20 October 2010 14:28:41 UTC