RE: [css-text ] font-size-adjust (was: @font-face and slow downloading)

After reading through this and the "@font-face and slow downloading"
threads on this list, I thought it might be useful to chime in to
explain the current tools that we at Typekit provide for developers to
work around these issues. Maybe they can provide some inspiration for
how the spec might deal with font rendering while loading and font
fallback issues.

I've explained font events and discussed our approach to several of
these issues at length in a recent series of posts on the Typekit
blog, but I'll summarize briefly in this email.
1. http://blog.typekit.com/2010/10/18/more-control-with-typekits-font-events/
2. http://blog.typekit.com/2010/10/29/font-events-controlling-the-fout/
3. http://blog.typekit.com/2010/11/02/font-events-fallback-fonts-and-styles-2/

The WebFontLoader code (which Typekit uses) provides font event
classes that are added to <html> as the fonts are loaded. There are
global classes (wf-loading, wf-active, wf-inactive) as well as
font-specific classes (wf-fonfamilyname-n4-loading,
wf-fonfamilyname-n4-active, wf-fonfamilyname-n4-inactive).
WebFontLoader also makes these events available in JavaScript through
callbacks that you can define, which is useful but not as relevant on
this list.

Using these classnames, the author can write CSS that emulates either
the "wait to render text until fonts are loaded" or "render with a
fallback, then with web fonts" approach. For example:

/* Wait to render text until fonts are loaded */

p {
  font-family: web-font, fallback-font;
}

..wf-loading p {
  visibility: hidden;
  /* ... or alternatively ... */
 color: transparent;
}

/* Render with fallbacks, then with web fonts */

p {
  font-family: fallback-font;
}

..wf-active p {
  font-family: web-font, fallback-font;
}


In addition, these class names can also be used to provide specific
styles for fallback fonts. Not just font-size adjustments, but also
line-height or any other property. For example:

p {
  font-family: web-font, fallback-font;
  /* Styles for the fallback font */
  font-size: 14px;
  line-height: 1.5;
}

..wf-active p {
  /* Styles for the web font */
  font-size: 18px;
  line-height: 1.2;
}


Obviously, it would be better if this was built into the UA instead of
added with JavaScript. If these same font event classes were provided
by the UA as pseudo-classes, authors could write essentially the same
CSS and not have to include any JavaScript to make it work:

:font-face-active p {
  ...
}


There's a case which was discussed earlier in the thread that these
font event class names don't handle: the author being able to hint a
specific timeout (in this case, for when the browser should switch
from wf-loading to wf-inactive). It might make the most sense for the
UA to set a default that can be changed by a user preference (and may
also change based on network conditions). This seems to provide a nice
balance of control:
- The author can choose what they want to happen in each state by
writing CSS using these pseudo-classes
- The UA has good defaults for how quickly we transition between
states and good default styles if the author didn't specify anything
with these pseudo-classes
- The user can choose how quickly they want their UA to transition
from wf-loading to wf-inactive if the font is taking a long time
- The user can choose whether they want the UA to continue downloading
the font and eventually transition from wf-inactive to wf-active if
the font takes too long
- The user can use these pseudo-classes in their own user stylesheets

--
Sean McBride
Developer | Typekit
typekit.com

Received on Friday, 5 November 2010 13:04:59 UTC