- From: Xiaocheng Hu via GitHub <sysbot+gh@w3.org>
- Date: Tue, 24 May 2022 17:39:21 +0000
- To: public-css-archive@w3.org
> I think things are a little fuzzier about whether developers want to block the entire page rendering until we can guarantee there will be no layout shifts from font loading. Let me reiterate that it's about tradeoffs. I think the following is a reasonable tradeoff that developers want to achieve: - If network condition is good, then I want guaranteed 0 layout shift, while a slight rendering delay is acceptable - If network condition isn't so good, then I can tolerate some layout shift as long as the rendering delay isn't too big `font-display: critical` ensures the first bullet. Together with the UA-defined timeout, the second bullet is also ensured. I don't know exactly how many developers want to do that (other than [this AMP example](https://bugs.chromium.org/p/chromium/issues/detail?id=1231827) and @Lorp's [previous comment](https://github.com/w3c/csswg-drafts/issues/7271#issuecomment-1129964898)), but given how widely `font-display: optional` has been recommended as a way to achieve a guaranteed 0 CLS but at a huge cost (page ends up in a fallback font), I think quite a number of developers currently using `font-display: optional` (possibly in combination with preloads) would actually prefer `font-display: critical`. > Can we render-blocking within a specific element via contain + font-display: critical? That sounds like `content-visibility`? -- GitHub Notification of comment by xiaochengh Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7271#issuecomment-1136250248 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 24 May 2022 17:39:23 UTC