- From: Noam Rosenthal via GitHub <sysbot+gh@w3.org>
- Date: Sat, 07 May 2022 13:46:28 +0000
- To: public-css-archive@w3.org
The problem with relying on preload in font rendering (as described [here](https://github.com/whatwg/html/issues/7896), is that it ties together fetching and font processing. Preloads are supposed to be a resource hint, something that changes the loading order, not something that affects rendering. By adding render semantics to preload, especially as the *only* way to block rendering on a particular type of resource like in the case of fonts, we make preloads into a mixed bag of features. I believe that if a style can be declared explicitly render-blocking (`<link rel=stylesheet blocking=render>`), then that style should be the one to carry on the chain of blocking the render, by declaring a particular font or image resource as render-blocking. I agree that preloading those fonts first is a best practice, but I think that what it warrants is a warning rather than disabling: allow people to render-block on fonts explicitly (if the containing style is render-blocking) but put a warning in the dev-tools console if that font has not been preloaded, encouraging to preload the font in addition to the block. I suggest that in the future we should enable the same for images in some form, perhaps similar to how we're going to tackle CORS settings in CSS images. What I want to avoid is making the render-blocking chain something that relies on disparate elements/headers in the same document rather than a clear chain of hrefs. -- GitHub Notification of comment by noamr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5924#issuecomment-1120212780 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 7 May 2022 13:46:29 UTC