- From: John Daggett <jdaggett@mozilla.com>
- Date: Fri, 27 Mar 2015 15:53:26 +0900
- To: www-style <www-style@w3.org>
- Message-ID: <CALYZoVMOrdMGuH47rD1g_BGi-YWbUODEvMM_0jQBAFKYxMgSnQ@mail.gmail.com>
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