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

Re: [css-font-loading] feedback

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 25 Jun 2014 18:08:12 -0700
Message-ID: <CAAWBYDAeK439=T15vj1275pGMcvfBpf+2HQ87DtXtyXugBwqNw@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "www-style@w3.org" <www-style@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>
On Mon, Jun 9, 2014 at 11:39 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Tue, Jun 10, 2014 at 3:35 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Mon, May 26, 2014 at 6:51 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>>> In the FontFace constructor you set status to "loading" at some point,
>>> but it's not clear from which task or microtask this is done. How can
>>> this be observed?
>> Hopefully fixed correctly - I now queue a task to set it.  (And do the
>> same with the font descriptors, which were similarly bugged.)
> Given that there's nothing that tells web developers this has changed,
> how is changing the state randomly useful? There's no way to observe
> this change.

Sure there is. It's completely possible for some task to queue after
the "loading" gets set, but before the part that sets it to
loaded/error runs.

Also, this just keeps things in line with network-loaded fonts, which
can have a significant period of time between "loading" and

> I think you want to cross-reference the "await a stable state"
> language by the way.

I switched to just using "queue a task", for simplicity.

>>> You need to use the [Exposed] attribute to make sure your interfaces
>>> are actually available in workers. See e.g. URL or Encoding for
>>> examples.
>> Do I need this on my FontFaceEvent interface too?  Added it to the
>> other interfaces.
> Although events seem special, they're not. So yes.

Cool, done.

Received on Thursday, 26 June 2014 01:08:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:43 UTC