W3C home > Mailing lists > Public > www-style@w3.org > August 2015

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

From: John Daggett <jdaggett@mozilla.com>
Date: Thu, 6 Aug 2015 15:35:10 +0900
Message-ID: <CALYZoVNSMX6uYJArfbysgJNM5+MNOex+eZVVXNYPhoQCOO=inA@mail.gmail.com>
To: Dominik Röttsches <drott@google.com>
Cc: www-style <www-style@w3.org>
Dominik Röttsches wrote:

> I am trying to get a clearer picture on the exact timing of the ready
> promise getting resolved:
>
> >From https://drafts.csswg.org/css-font-loading/#font-face-set-ready :
> "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.

Ex:

  @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; }

  <p>BBB</p>

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

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

Regards,

John Daggett
Mozilla Japan

[1]
http://people.mozilla.org/~jdaggett/tests/test_unicode_range_loading.html

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

This archive was generated by hypermail 2.3.1 : Thursday, 6 August 2015 06:35:40 UTC