[css-fonts-4] font-display: optional without relayout

[jakearchibald]

https://drafts.csswg.org/css-fonts-4/#font-display-desc

I originally thought font-display: optional was designed to provide web fonts in a way that avoided swapping or flash-of-invisible-text, at the expense of getting a fallback font for the first visit. This is kinda backed up by a note in the spec:

the font is used if it’s already downloaded and available, but otherwise a fallback is used for the rest of the page’s lifetime instead. The font might download in the background and be available to future page loads

However, the prose doesn't really define the behaviour.

https://static-misc.glitch.me/optional-font-load/

In Chrome & Firefox at least, the page may briefly render with invisible text (using layout from a fallback font), causing the green bar to move when the page is laid out again using the web font. This is the kind of layout instability I thought font-display: optional was designed to avoid.

Proposal:

When the browser discovers a part of the page that needs a font-display: optional web font, it must:

1. Block rendering.
2. Makes an "only-if-cached" fetch for the resource.
3. Let font be null.
4. If there's a valid font response that isn't stale, set font to that resource.
5. Otherwise, set font to the result of getting the next item in the font-family stack.
6. Unblock rendering (if it hasn't already been unblocked during the previous line).
7. If there was no response, or the response was stale, make a low-priority request for the font resource (just to populate the cache for next time).

We already block rendering when getting regular font resources from disk, so blocking rendering shouldn't really be a problem here, unless we expect the above to be significantly slower than loading installed fonts.

Do you think we can safely change font-display: optional to behave similar to above? If not, do we need a new value that behaves like this?

[tabatkins]

Sigh, yes, that is absolutely the intention of that value. The only reason the spec mentions "extremely small block period" for optional and fallback is because implementors complained that a 0s block period technically disallows loading from cache, if the cache is slow enough that the timer can advance before it loads.

[jakearchibald]

Yeah, I think at the time we didn't have a good way to express it via fetch.

[tdresser]

Web fonts are showing up as one of the primary causes of layout instability. I'd love to be able to give web devs the advice "apply font-display:optional and this won't be a problem", but today we can't do that.

Any thoughts on next steps here?

[chrishtr]

I agree that we need this mode. Unfortunately, today use of a local, pre-cached web font incurs a two renders to draw most of the time, because the there is no way to make the font block the rendering entirely for a limited time.

Browsers can add heuristics to anticipate this, but there is an inherent tradeoff about whether the font blocks all of rendering that, for high-performance sites, the site author should be allowed to make.

[jakearchibald]

There must be a way, as it's what we do for regular installed fonts.

[xiaochengh]

For some context, for font-display:optional, when the web font is already cached, Chrome (80.0.3987.7) in some cases may synchronously resolve the network request during style recalc and use it immediately for rendering. This is what I observed after reloading the test case (https://static-misc.glitch.me/optional-font-load/) for a few times.

This sounds like the desired behavior, and I'd love to see it enforced by the spec.

[tabatkins]

All right, pushed some new text that should make the intent much clearer:

If the font can be loaded "immediately"
(such that it's available to be used for the "first paint" of the text),
the font is used.

Otherwise, the font is treated
as if its [=block period=] and [=swap period=] both expired before it finished loading.
If the font is not used due to this,
the user agent may choose to abort the font download,
or download it with a very low priority.
If the user agent believes it would be useful for the user,
it may avoid even starting the font download,
and proceed immediately to using a fallback font.

An ''optional'' font must never
cause the layout of the page to "jump" as it loads in.
A user agent may choose to slightly delay rendering an element using an optional font
to give it time to load from a possibly-slow local cache,
but once the text has been painted to the screen with a fallback font instead,
it must not be rendered with the ''optional'' font for the rest of the page's lifetime.

[chrishtr]

The latest commit is not quite enough for font-display: optional I think:

1. It says that the font should only be used if it "can be loaded 'immediately'". This needs to be clarified to allow for async loading from an on-disk cache, service worker, or other low-latency network source. I think it should be reworded to allow a "short" block period. The 100ms of bock periods elsewhere in the spec sounds fine to me.

2. It needs to say that the font blocks all rendering until it's known that the font won't come through in the block period, not just rendering of elements the font applies to.

3. The font needs to always be loaded, regardless of whether it applies to any elements on the page. This is necessary to avoid extra, inefficient forced style or layouts, and allow the fetch (either from cache or network) to start as soon as the font element is parsed. This also is needed to mitigate the "blocks all rendering" behavior of item 2 above.

[chrishtr]

Feedback from other vendors and community members is also needed for these proposed semantics.

[chrishtr]

The rationale for allowing low-latency network loads in addition to cache is:

• Caches sometimes have performance similar to fast networks, especially when inter-process IPC overhead is also taken into account
• Allows for service worker caching
• Will allow fast sites to have a chance to have perfect rendering with web fonts, even on the first load