New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 898083 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Feature



Sign in to add a comment

font-display: optional should not create an unstable render

Project Member Reported by jakearchibald@chromium.org, Oct 23

Issue description

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

Open the above page in a fresh tab.

The green line jumps because the page is laid out using a fallback font, then re-rendered quickly using the web font.

https://drafts.csswg.org/css-fonts-4/#font-display-desc - the spec is unclear what to do in this case (I think it should be more specific). But IMO:

Blocking in this case should be total render blocking. Nothing further should be laid-out or painted until the font is fetched (basically the same behaviour we have for system fonts).

The font should be fetched with a cache mode (https://fetch.spec.whatwg.org/#concept-request-cache-mode) of "only-if-cached". If the fetch fails, use the fallback & never swap.
 
Seems like Firefox behaves the same. It's less clear what Safari does. It seems to be unstable during the initial render if the webfont arrives from the network quickly.

I haven't seen Safari rerender if it can get the font from that cache.
*Technically* this behavior is mandated by the spec, at least sorta. "optional" gives the font a very small block period; during the block period, the browser must render with an invisible fallback font.

I agree that this is bad behavior tho. Assuming that this can be fixed in impl, I'm happy to change the spec as appropriate.
Cc: futhark@chromium.org
Components: -Blink>CSS
Labels: -Type-Bug Type-Feature
Status: Available (was: Untriaged)

Sign in to add a comment