Re: [css-fonts] Proposal for standardizing font timeout behavior

On Sun, Oct 26, 2014 at 9:31 PM, John Daggett <jdaggett@mozilla.com> wrote:

> I think it would be a good idea to have more consistent behavior
> across browsers for font downloads. It definitely sucks to be using
> Mobile Safari and get stuck on a page that remains blank until the
> end of time because the font load stalls on a flakey network
> connection. But I'm not sure how valuable it is to specify the
> Firefox/Chrome behavior as "must" behavior.


I agree, standardizing a common "must" is a non-goal. Different content has
different requirements, and the very fact that various UA's have different
strategies is an illustration that there isn't a single universal default
that works in all cases (e.g. even "block forever" is reasonable in some
cases). With that in mind, we:

a) owe it to developers to explain current behavior differences across
various UAs
b) allow developers to customize said behavior to fit requirements of their
application + content

Not being able to control how and when text is rendered is a performance
and UX red flag and a common roadblock for adoption of webfonts, despite
all of their other benefits - searchable, selectable, zoomable, high-DPI
friendly, etc.


> Font loads generally occur after stylesheets have loaded and layout
> has started. This will be after other content on the page will
> already be queued for fetching. Depending upon the complexity of a
> page, the delay in loading a font may not be the actual load time
> for the font but the fact that the font is queued behind a lot of
> other content.

As for the 'font-rendering' descriptor/property, I'm somewhat skeptical
> that giving authors control over the timeout is the right approach here.
> I think it would be better to give authors some form of preload hint
> for @font-face fonts so that they could tag fonts that should begin
> loading after the @font-face rule is parsed.
>

What you're highlighting is the (missing) ability to control and refine
*when* the font request is dispatched. This is a separate concern from what
we're trying to address with font-rendering... I agree that we need a
"fetch this now, don't wait for layout" to move the download earlier in the
page cycle, but this still does not provide any control over eliminating
unnecessary delays in text rendering - e.g. I may have initiated the
request earlier, but that doesn't meant request will finish before UA is
ready to paint text pixels (with a fallback font).

Resource Hints provides a partial solution for question of "when", but it
has its limitations as well: you must duplicate resources URLs, and the
parent document must know the resource URL to begin with... which is often
not possible. As a concrete example, I request a dynamics CSS stylesheet
from Google Fonts, and I don't know the actual font URL until that CSS is
available -- Google Fonts serves a dynamic @font-face based on UA, current
font version, etc. At best, I can do a rel[preconnect] to final origin, but
because the final URL is unknown, I can't force an actual early font fetch
until much later.

The behavior for this descriptor/property can also be done via
> script using the Font Loading API. I think it would be better to let
> authors experiment with that first and then consider whether there
> are simple use cases for which a descriptor and/or property would
> simplify things.
>

We have, and this proposal is the result of that experience. We have a
number of very latency sensitive applications at Google where delaying text
rendering is a non-starter... and reason why webfont adoption has been a
very hard sell (read, impossible). Further, based on my experience of
working with the broader community (including early feedback on this
proposal), we are not alone with these requirements.

First, Font Loading API is a huge step forward. Can't wait for it to ship
in FF, and hoping IE and Safari will be fast followers. However, Font
Loading API (a) does not address all of the necessary use cases, and (b)
requires high developer overhead. Consider the proposed font-rendering
behaviors:

- mandatory <time>: can be implemented via Font Loading API... set
visibility to hidden and wait for the font promise to resolve to unhide
text.
- optional / swap <time>: not implementable in a performant way. We can do
a .check() to see if font asset is "available" at an arbitrary point in
time, but we have no idea when the UA is ready to paint text -- the latter
can be before or after my arbitrary timeout... If its before then I've
already delayed rendering (not acceptable), and if its the latter, then I'm
delivering subpar UX by forcing an unnecessary early fallback. Further,
note that picking a single timeout is effectively impossible -- this will
vary based on device in use, network weather, etc.

font-rendering allows us to deliver optimal text rendering by defining the
strategy we want the UA to take at the earliest point of when it is ready
to paint text pixels on the screen: UA races font request with its usual
render-tree+layout+etc work, then at the earliest point in time when its
ready to paint text it applies our strategy... mandatory: wait for font;
swap: fallback, rerender later; optional: first render wins.

A bit more background here (note that we changed the strategy names since):
https://github.com/KenjiBaheux/css-font-rendering/pull/5#issuecomment-56899734

---

tl;dr.. font-rendering:

1) explains existing UA rendering strategies in well defined terms; UA's
can set any defaults they like.
2) enables developers to define optimal text rendering strategy for their
content, which you can't achieve via JS/Font Loading API.
3) keeps rendering concerns in CSS and make delivering fast text rendering
simple.

ig