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 08:22:14 -0700
Message-ID: <CAAWBYDAxp_FdiKgSBXMK8eaxq3gW2C4mwiWfVdkn=x2s0kVbOA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: www-style list <www-style@w3.org>, Alex Russell <slightlyoff@google.com>
On Mon, Apr 8, 2013 at 7:37 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Mon, Apr 8, 2013 at 3:26 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Fri, Apr 5, 2013 at 3:02 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>>> 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.
>
> How does ready() not provide the same functionality provided it will
> gain progress notifications going forward?

Sorry, I accidentally labelled Font as being an EventTarget as well,
and you may have assumed that I'd simply left out some events from the
IDL.

Font is not an EventTarget.  It has nothing but .ready() added to it.
The only events are on FontList, and used to address usecase #3 in my
original email, which is not possible to easily do with
ProgressFuture.

If you actually are saying that you think having FontList.ready()
return a ProgressFuture would solve the case, could you explain how
you see that working?

~TJ
Received on Monday, 8 April 2013 15:23:04 UTC

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