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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 30 Jun 2014 14:53:26 -0700
Message-ID: <CAAWBYDD3zQGNys7+5VB-pzyJ9mVg8fW1wu2uwfMXgCZ_Ump-Lw@mail.gmail.com>
To: Cameron McCormack <cam@mcc.id.au>
Cc: "www-style@w3.org" <www-style@w3.org>
On Sun, Jun 29, 2014 at 7:07 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> The spec says, when a font in the FontFaceSet begins loading, to replace
> [[ReadyPromise]] with a freshly created pending Promise object if
> [[ReadyPromise]] is already fulfilled.
> First, I notice  that it says "fulfilled" rather than "settled". Although
> the spec never rejects [[ReadyPromise]], script could.  Is it worth making
> document.fonts.ready resilient to that?

How can script reject the [[ReadyPromise]]?  It doesn't have access to
the promise's reject handler.

> Second, detecting if [[ReadyPromise]] holds a fulfilled promise is not
> really something you can do with the Promise API.  Well, you could do this
> (maybe?):
>   var fulfilled = false;
>   readyPromise.then(function() { fulfilled = true; });
>   setTimeout(function() {
>     if (fulfilled) {
>       readyPromise = new Promise(...);
>     }
>   }, 0);
> but I'm not really sure if this is an idiomatic use of Promises.

It's easier than this.  The UA already maintains counters of loading
fonts, for the purpose of firing the events.  (This can be done
non-magically, since the actual load machinery is UA-controlled, so it
can go increment/decrement some hidden state to communicate this
information.)  It can use the same counters to keep track of the
promise states.

Received on Monday, 30 June 2014 21:54:14 UTC

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