- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 8 Apr 2013 07:26:39 -0700
- 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. ~TJ
Received on Monday, 8 April 2013 14:27:30 UTC