W3C home > Mailing lists > Public > www-style@w3.org > September 2012

Re: [css3-fonts] rethinking font load events

From: Sebastian Zartner <sebastianzartner@gmail.com>
Date: Fri, 7 Sep 2012 18:01:19 +0200
Message-ID: <CAERejNaqs9Y53kYHwmubhZbzX1yjenmKthW=HBVh-jSoW554FA@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Glenn Adams <glenn@skynav.com>, John Daggett <jdaggett@mozilla.com>, www-style list <www-style@w3.org>
>> 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().

Received on Friday, 7 September 2012 16:01:50 UTC

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