When a webfont fails, a system face must catch — not a blank
Aliases: font stack · failed webfont · system face catch
What it is
A file can never arrive: the host is down, the request is blocked, the certificate is wrong, the user is offline. Failure is not “wait a bit more.” This swap is cancelled. Webfont failure fallback means a usable system face still paints the letters. A blank, tofu, or an invisible button turns a resource error into a missing feature. That is not the same interval as a load still in flight. In-flight might yet succeed. Failure has no next frame.
Why it happens
A font stack is an ordered list; the engine takes the first face that works. The custom face sits in front; on failure it should fall to a system family behind it. If the stack names only the custom face, or a blocking strategy keeps the ink transparent after failure, there is no next face and drawing stops on a hole. Failure and timeout often share a path with “still loading,” so failure becomes infinite FOIT. A system face as last resort is not an aesthetic compromise. It lets the reading task start when the resource layer has already lost. The stack also has to cover the script: Chinese body must land on a system face that actually contains Han. Landing on a Latin-only face is a paragraph of tofu.
Where it stops holding
A wordmark that fails into a system face loses some identity, which is still better than vanishing; if the mark also has a graphic version, that graphic is the identity catch and the stack is the copy catch. An icon font that fails cannot be “read” by a system face from private-use code points; it needs an SVG or a text label as a second path. Faces that only resolve on a corporate intranet are expected to fail off-net, which is exactly when the system stack must be complete. If the user has uninstalled a named system face, the stack needs a further rung; do not assume every machine still has the face you pointed at.
Applying it
- After the custom face, name system families, with Chinese and Latin landing on faces that actually contain those glyphs. Do not ship a stack of one webfont.
- Block the font URL (failure, not throttle) and open the page: body should be readable at once in a system face, and buttons should have labels. If the screen is still blank, failure was treated as eternal loading.
- After timeout, force the next face in the stack. Do not leave a block hanging in the failed state.
Related
- Same group: F4.15.1 Text during a custom-font load needs an explicit display strategy · F4.15.2 A long invisible wait hurts more than painting a fallback first · F4.15.3 Metric mismatch between fallback and target shifts the layout after load
- Nearby: F4.07 Typeface choice · E6.10 Error and fallback pages
- Search terms:
font stack·webfont failure·system font fallback