W3C home > Mailing lists > Public > www-style@w3.org > July 2014

Re: [css-font-loading] replacing [[ReadyPromise]]

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 2 Jul 2014 23:26:59 -0700
Message-ID: <CAAWBYDD_raDRX2thFMZ2S4JFPEwHwNSNr7EBdisrg3s9NbGQ8g@mail.gmail.com>
To: Cameron McCormack <cam@mcc.id.au>
Cc: "www-style@w3.org" <www-style@w3.org>
On Wed, Jul 2, 2014 at 9:18 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> I've just noticed there is one issue with the way [[ReadyPromise]] is
> initialized with a pending promise when the FontFaceSet is first created and
> replaced whenever we transition from "no fonts loading" to "some fonts
> loading".  It allows authors to write code that "works" if they are tracking
> the very first set of fonts loading and "doesn't work" with the same code
> pattern for subsequent font loads.
>
> For example:
>
>   // Assume document.fonts is empty and has been empty since the
>   // document was created.
>   var face = new FontFace(...);
>   document.fonts.ready.then(function() { alert("loaded"); });
>   document.fonts.load(face);
>
> This will alert once the font loads, because document.fonts is not replaced
> when with a new Promise object as soon as the FontFace starts loading.
>
>   // Now continue on once |face| has been loaded and the
>   // [[ReadyPromise]] has been replaced.
>   var face2 = new FontFace(...);
>   document.fonts.ready.then(function() { alert("loaded"); });
>   document.fonts.load(face2);
>
> This will alert before face2 loads, because document.fonts.ready is the
> already-fulfilled Promise representing the first FontFace's load.
>
> We could avoid this by having the FontFaceSet initialized [[ReadyPromise]]
> to a Promise that is already resolved with the FontFaceSet.

Makes sense; I like the consistency of your proposal.  Fixed.

~TJ
Received on Thursday, 3 July 2014 06:28:18 UTC

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