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

Hi Michael,

Thank you for your reply.

On Thu, May 7, 2009 at 9:05 PM, Michael Jansson <mjan@em2-solutions.com> wrote:
> 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.

This is true, assuming the font is not already cached. However this is
how other media are handled. For example an image without width/height
attributes will generate a redraw if it finishes downloading after
that part of the page has been drawn, as would a slow imported CSS
file.

> Please note that a single web font would typically be re-used on many web
> pages

While not explicitly addressed in this working draft, I think there is
an implicit assumption that a browser would cache web fonts, as it
would other downloaded media such as CSS files, HTML files, images
etc. For example, in 4.2 Example 1:
“Once one of these @font-face definitions has been dereferenced, the
data will be in the UA cache for other faces that use the same URI.”

This would make the web font into a local font, at least as long as it
remained in the cache.

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

While subsetting technology exists, it’s not likely to be widely used
given the lack of tools and the extra steps required. Subsetting  is
also currently impractical for any site that is actually updated, as a
new subset font needs to be generated any time currently excluded
characters are used in the content.

As a data point, subsetting the M+ Japanese font for a single page via:
    http://fonts.philip.html5.org/
resulted in a drop from 586KB to 22KB. The M+ font is currently only
at 4000 glyphs though (normal Japanese fonts are 8000+ glyphs), and I
was only using 94 glyphs.

> Still, I would recommend a redraw
> on the first page and a block on the other pages when the web font is
> cached.

In effect that’s what I’m saying too, as once the font is cached the
UA shouldn’t re-download it.

> I would thus support the current wording of the specification

I think my saying “must” was foolish—first post and all :) Would
“should” be acceptable?

> It's up to the implementor to make the most out of this

It’s been pointed out to me that the working draft basically says UAs
should do the best they can, and it’s possible that this is something
that will be optimised. The unoptimised state is pretty bad though :/

> I would recommend that web fonts are handled no different
> than images in terms of blocking the layout rendering.

I think images are a little different as they can be progressively
rendered. A more apt analogy might be scripts, and IE’s block on load
when the script is in the <head> has led to the common practice of
putting scripts right before the closing </body> tag.

Thanks for your time

peace - oli

Received on Thursday, 7 May 2009 15:18:34 UTC