Re: [css-font-loading] Timing clarification of ready attribute/promise

Dominik Röttsches wrote:

> I am trying to get a clearer picture on the exact timing of the ready
> promise getting resolved:
> >From :
> "The ready attribute contains a Promise which is resolved when the
> document is done loading fonts"
> And further down, in the non-normative note:
> "The ready promise is only fulfilled after layout operations complete
> and no additional font loads are necessary."

The normative text is correct and the note is explaining what happens
for that to be true.

When a font loads it may or may not contain a glyph for a given
character. So *another* font within the same fontlist or font family may
need to be initiated after the first font is loaded. The "layout
operations complete" means that after a given font loads, font matching
has been re-run and no other font loads initiated. When precisely
painting occurs is not specified.


  @font-face {
    font-family: fontA;
    src: url(fonts/markA.woff); /* only supports 'A' */

  @font-face {
    font-family: fontB;
    src: url(fonts/markB.woff); /* only supports 'B' */

  p { font-family: fontA, fontB; }


After fontA is loaded, layout is run and fontA does not contain a glyph
for 'B' so the load of fontB is initiated. The ready() promise will be
resolved after *both* fontA and fontB loads complete.

This is a somewhat unusual case to some degree but the ready() promise
is defined to allow the author to know that "all loads are done" with

For Gecko, we have a unicode-range test that tests similar situations
where multiple font loads can occur [1]. It fails under Chrome so it may
be that the "layout operations complete" behavior has not been handled


John Daggett
Mozilla Japan


Look for the failure below which asserts the correct state of fonts after
the ready() promise resolves:

TEST 10 multiple fonts with overlapping ranges, all with default ranges,
only last one supports character used (@font-face rules) after load


Received on Thursday, 6 August 2015 06:35:39 UTC