W3C home > Mailing lists > Public > www-style@w3.org > May 2009

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

From: David Hyatt <hyatt@apple.com>
Date: Thu, 07 May 2009 11:08:27 -0500
Cc: www-style@w3.org
Message-id: <931BCB4D-8559-49F5-B001-70508ED173E3@apple.com>
To: w3-style@boblet.net
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.


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.

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

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 12:34:26 UTC