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

Re: [css3-fonts] FontLoader v2

From: Sean McBride <seanmcb@adobe.com>
Date: Thu, 13 Sep 2012 15:28:45 -0700
To: John Daggett <jdaggett@mozilla.com>
CC: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>, Glenn Adams <glenn@skynav.com>
Message-ID: <34357091-4AB2-4F13-BD0F-5E6F55782DB2@adobe.com>
On Sep 10, 2012, at 6:34 PM, John Daggett wrote:

Sorry to be a nag but can you describe (or have your coworkers post
about) why per-font load events are important?  Could you describe the
use case in a little more detail?  What are the operations which are
done per-font rather than simply after all fonts are ready?

John, I described some of the Typekit use-cases for the per-font events in my previous message on the other thread ( http://lists.w3.org/Archives/Public/www-style/2012Sep/0220.html ), but I'll summarize them again here for you:

- Typekit provides JS callbacks and CSS classnames to our end users on a per-font basis. In order to provide these in a timely/meaningful manner, per-font events are critical.
- On typekit.com<http://typekit.com>, we make use of the per-font events all over the place:
  - In the browsing interface, each font card renders as soon as the individual font has loaded, and fonts are requested in batches asynchronously.
  - In the lists interface, each font in the list is measured for width and rendered as soon as that individual font has finished loading. We start by requesting the fonts at the top of the list first.
- Our end users might have many uses for these per-font events, but here are a few I can think of:
  - Displaying different modules of the page as soon as the fonts they require are ready, instead of waiting for all the fonts.
  - Making a measurement for a headline to fit the line of text to the available width as soon as the single headline font is ready.

Having per-font events is important for having a more performant page that displays elements or modules as soon as the necessary fonts are available (instead of waiting for them all). It's also important for simplifying the callback model for pages that load different fonts incrementally over time.

Fundamentally, Typekit starts with per-font events and builds up from there. If there are other fonts on the page from other web font providers, we don't want the delivery speed of those fonts to affect when we can say that the Typekit fonts are done loading. That's another reason why the overall loadingdone event wouldn't be usable for us. Regardless of what other fonts are on the page, our kits should only track the loading of the fonts that we provided.
Received on Thursday, 13 September 2012 22:28:30 UTC

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