- From: Richard Fink <rfink@readableweb.com>
- Date: Thu, 11 Nov 2010 18:37:43 -0500
- To: "'Sean McBride'" <sean@typekit.com>, "'Yuzo Fujishima'" <yuzo@google.com>, <www-style@w3.org>, <www-font@w3.org>
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