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

Brad Kemper wrote:

> Is there any way to just grab kerning, tracking, and width info first,
> so that the page can be drawn with the right geometries prior to
> getting all the glyph path information? If that would be faster, maybe
> it could be an additional standard for loading that separately if
> available (as in, from a separate file). Then it wouldn't look as
> FOUC-like, because it wouldn't force a reflow.

Interesting idea but you still will have a reflow after the
kerning/metrics are loaded and at least a second repaint when the glyphs
are available.  Shaping would still result in a reflow.  For this to
work, user agents would really need to be handling the full text layout
pipeline to be able to treat "fonts with metrics but no glyphs"
differently from normal fonts.  Most user agents use platform text
API's.  The delay until reflow is not necessarily a function of font
size and network bandwidth but more a function of latency and the
sequence in which the browser loads page content, so jiggling font
structure and introducing more complex handling is probably not going to
be a big win.

We didn't implement the Webkit-style no-draw-until-load in Firefox when
implementing TTF/OTF font linking for Firefox 3.5.  Some argued for it
but I was concerned about users not being able to see page content until
a font loaded.  While FOUC-like flashing sucks, only content that uses a
downloadable font will be affected, the degree this affects a given page
will really depend on how downloable fonts are used on a given page.

Using a transition to fade in the text that uses a downloadable font
might be one way to ameliorate the flash effect.  Having an event that
fired after each font load might also allow authors interesting ways of
working around this problem.

John Daggett
Mozilla Japan

Received on Friday, 8 May 2009 04:15:41 UTC