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

[css-font-loading] loading fonts and changes in status

From: John Daggett <jdaggett@mozilla.com>
Date: Fri, 27 Mar 2015 15:53:26 +0900
Message-ID: <CALYZoVMOrdMGuH47rD1g_BGi-YWbUODEvMM_0jQBAFKYxMgSnQ@mail.gmail.com>
To: www-style <www-style@w3.org>
There are a couple places in the Font Loading spec where the behavior of
implementations doesn't match what the spec defines for precisely when
changes to the status field of FontFace objects occur.

In Section 2.1, when a binary blob is used to create a FontFace object,
the initial state of the object is implied to be "unloaded". The spec
states:

  If font face’s [[Data]] slot is not null, queue a task to set
  font face’s status attribute to "loading".

This implies:

  var f1 = new FontFace("test", fontDataBlob);
  assert(f1.status == "unloaded");

Yet the Chrome implementation starts loading the data immediately, so
for font blob FontFace objects, the status attribute is *never* unloaded:

  var f1 = new FontFace("test", fontDataBlob);
  assert(f1.status != "unloaded");

Similarly, in section 2.2 where the load() algorithm is defined, step
(3) indicates that after a call to load() the status is always "loading":

  3. Otherwise, set font face’s status attribute to "loading",
     return font face’s [[FontStatusPromise]], and continue
     executing the rest of this algorithm asynchronously.

This implies:

  var f2 = new FontFace("test", "local(Georgia)");
  f2.load();
  assert(f2.status == "loading");

Here too Chrome may decide to trivially load the font such that the
status after the load() call is "loaded" instead.

In both these cases I think the implementation behavior of Chrome and
Gecko is better than what the spec currently specifies. I think we
should update the spec to allow implementations to immediately switch
the status to loaded/error if that's a trivial task that doesn't need to
run asynchronously.

Regards,

John Daggett
Received on Friday, 27 March 2015 06:53:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:30 UTC