Re: [css3-fonts] rethinking font load events

On Fri, Sep 7, 2012 at 9:01 AM, Sebastian Zartner
<sebastianzartner@gmail.com> wrote:
>>> Maybe the misunderstanding lies in when "allcomplete" is actually
>>> triggered. So I assume you wouldn't trigger it if there are just
>>> client fonts used in the page, i.e. B would not be executed at all.
>>> I interpreted the event to mean "all fonts are loaded and displayed",
>>> independent of having web fonts in the page or not. So the event would
>>> always at least be fired once.
>>
>> If there is at least one @font-face being used, yes, "allcomplete" is
>> guaranteed to fire at least once.
>>
>> However, that's irrelevant for the question at hand.  Assume that A is
>> running some time *after* the page load, so at the time A starts,
>> FontLoader.readyState is definitely "idle".  You picked up on the
>> problem - if all you do is set up B to run on an "allcomplete" event,
>> but A didn't actually trigger any new loads, B will never run at all.
>> That's the problem we're solving here.  Without notifyAfterCompletion
>> or something similar (like an explicit promise object), you have to do
>> an annoying amount of additional work, which depends on style
>> flushing.
>
> You didn't read carefully. I put a suggestion in my post.
> What about letting "allcomplete" always be fired when fonts are loaded
> and displayed independently of being defined via @font-face, i.e. also
> if the page just contains local fonts?
> Doing so B would work as a normal callback function and there wouldn't
> be a need for notifyAfterCompletion().

No, I read carefully, you're just misunderstanding.  ^_^

If you're still talking about the *initial* fire at page start, that's
irrelevant to the situation we're talking about, and has no connection
with the use-case for notifyAfterCompletion().

~TJ

Received on Friday, 7 September 2012 16:41:35 UTC