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

While I agree that freezing the layout while a web font is being 
downloaded is indeed a usability issue, I wouldn't agree with your 
solutions. If the UA is required to always redraw then you are 
effectively requiring all web pages that uses web fonts to flicker, i.e. 
redraw at least twice.

Please note that a single web font would typically be re-used on many 
web pages. Even with a quite large web fonts, you are only going to 
notice a "freeze"on the initial page (assuming the UA implements a sane 
caching algorithm).  Also, even with Han/Hanzi/Kanji fonts (e.g. Chinese 
font) there are technologies to compress and subset the font data down 
to less than 100kb for typical text use (a technique used by GlyphGate 
through XcgfK fonts) so that delay may not be too bad. Still, I would 
recommend a redraw on the first page and a block on the other pages when 
the web font is cached.

I would thus support the current wording of the specification. The UA 
may or may not block depending on how long it will take to access the 
web font. It's up to the implementor to make the most out of this. 
Stalling a page during an initial download of a web font is clearly not 
what the user would expect though. I would recommend that web fonts are 
handled no different than images in terms of blocking the layout rendering.

Regards,
Em2 Solutions AB
Michael Jansson



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.”
>
> Thank you for your time
>
> peace - oli studholme
>
>
>

Received on Thursday, 7 May 2009 12:06:28 UTC