W3C home > Mailing lists > Public > www-style@w3.org > April 2013

Re: [css-font-load-events] Using Futures

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 8 Apr 2013 07:26:39 -0700
Message-ID: <CAAWBYDC-trn_HxxpboDwPq--SRghFPYQmrNQaomr_NeU370OOA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: www-style list <www-style@w3.org>, Alex Russell <slightlyoff@google.com>
On Fri, Apr 5, 2013 at 3:02 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Thu, Apr 4, 2013 at 6:35 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> To address use-case #3, the API has two pieces.  If you care about the
>> loading status of individual fonts, look for the relevant Font object
>> and call its ready() function to obtain a Future which is resolved
>> when the font is done loading, or cancelled when the font load has an
>> error.  This replaces the loadstart/load/error events.  The
>> loading/loadingDone events are unchanged - they're useful for
>> providing UI indicating whether fonts are loading or not, rather than
>> a one-off "tell me when fonts are ready", which is what the .ready()
>> future is for.
> I think we should remove the EventTarget dependency for now and
> address this use case at a later point when futures gain a way to get
> insight into the progress of the operation they represent the result
> for.

This doesn't make sense.  We do want ProgressFuture for Font.ready()
(so you can indicate when a font *starts* loading, which is currently
hidden), but the events I've left are on FontList, and can't be
replaced by a ProgressFuture.

> Also, given that you are using futures, exposing synchronous state
> such as checkFont() does not seem like a good idea. loadFont() should
> be sufficient.

I'm fine with removing it, but I didn't have insight as to why John
added it in the first place, so I was conservative and left it.

Received on Monday, 8 April 2013 14:27:30 UTC

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