Re: CSS3 Web Fonts issue with ‘block on download’

On May 7, 2009, at 6:26 AM, Oli Studholme wrote:

> Hi All,
>
> I recently came across an issue when an @font-face takes a long time
> to download (eg large font, slow server etc). In the font-matching
> algorithm the CSS3 Web Fonts working draft says:
> 4.4 “The UA may choose to block on this download or may choose to
> proceed to the next step while the font downloads.”
>    http://www.w3.org/TR/css3-webfonts/#algorithm
>
> Firefox implements this by proceeding with the font matching algorithm
> while the @font-face downloads. This results in the content being
> drawn quickly, with a redraw once the @font-face font has downloaded.
> Safari implements this by ‘blocking on download’ (I’m guessing that
> means ‘stop the text layout algorithm until @font-face finishes
> downloading’), which if the @font-family font takes a long time to
> download can mean the user sees what appears to be a broken page. This
> is especially noticeable if the font is used for body text. This has
> led to the following Webkit bug:
>    https://bugs.webkit.org/show_bug.cgi?id=25207
> which contains this demonstration:
>    http://hsivonen.iki.fi/
>
> While requiring a redraw has visual and performance drawbacks, I think
> permitting nothing to be displayed until a font downloads presents a
> serious usability issue, especially for people accessing pages with
> large double-byte fonts or over slow connections. I humbly submit this
> sentence should be changed to “The UA must proceed to the next step
> while the font downloads.”


When I first implemented @font-face in WebKit, I tried displaying the  
wrong font before displaying the right font.  The end result looked  
terrible.  It basically looked like the infamous FOUC.

http://bluerobot.com/web/css/fouc.asp/

You don't want to see an unsightly visual flicker every time you use  
an uncached downloadable font.  I think the behavior of just showing  
nothing until the font is loaded is much better.  WebKit should  
probably eventually display the wrong font after a certain timeout  
period, but displaying the wrong font immediately is as bad as FOUC.

In any case I definitely think this should be left up to  
implementations to decide.  I don't see this as something that should  
be in the spec.

dave
(hyatt@apple.com)

Received on Thursday, 7 May 2009 16:09:09 UTC