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

Thursday, November 04, 2010 8:32 PM <sean@typekit.com>:

Sean wrote:

>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.

First, a thanks for responding
(http://lists.w3.org/Archives/Public/www-style/2010Oct/0567.html) with your
explanation of how, exactly, the font loading events tracked by the
JavaScript Webfontloader can translate into pseudo-classes for handling the
problem of FOUT and/or the problem of transitioning from the fallback to the
web font.

As I wrote, the capability *already exists* using JavaScript and is widely
used - making the case for simply moving it to the presentation layer of CSS
all the more compelling. User Agents *already support* the desired
behavior(s), the question is whether it remains where it is, in the
programmatic layer, or not.

Yet some objections have been raised.
Yuzo Fujishima wrote:

>>Rationale:
>>1. Through the discussion so far, it seems to be very difficult to find a
>>common ground with that everyone is reasonably happy. Hence mandating
>>a behavior doesn't look reasonable.
>>2. Allowing authors to control this tentative and transitional behavior
>>seems to be an overcommitment for me, especially as a browser developer.

Firstly, I haven't sensed it to be "very difficult to find a common ground".
All acknowledge that a problem exists. Proof of the need for a solution
exists in the Webfontloader script and it's deployment.
Authors can already control "this tentative and transitional behavior": the
"overcommitment" has already been made.

This being the case, does it not make sense to make the solution more
elegant and accessible?

I understand there is a cost to everything and don't wish to make a mountain
out of molehill.
However, just as in the past, the jarring ugliness of the Flash Of Unstyled
Content was ultimately left behind, I think it's worth some effort to
extinguish the Flash Of Unstyled Text, as well.
I don't think I'm alone in asking, "Why settle for less?"

Regards,

Rich

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf
Of Sean McBride
Sent: Thursday, November 04, 2010 8:32 PM
To: www-style@w3.org
Subject: 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 Thursday, 11 November 2010 23:38:08 UTC