- From: Xiaocheng Hu via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Jun 2022 16:55:32 +0000
- To: public-css-archive@w3.org
@litherum I think base64 encoding is a strictly (much) worse solution than this proposal in many aspects: - Deployment. base64 is much harder to deploy, as you already pointed out - Memory. base64 takes more space, as you also pointed out - Loading performance. base64 forces UA to block rendering on loading the entire font without any way out, while this proposal allows UA to unblock early if its internal timeout is hit (aka when connection is bad) Also, here is an [example](https://bugs.chromium.org/p/chromium/issues/detail?id=1231827) where the author wants to make a big font render-blocking. @jfkthame To achieve the same purpose (block rendering, then unblock on font load or timeout), it will be much more complicated, and hence error-prone, with the Font Loading API. This is the common problem of polyfills, and the reason why we are speccing new features. I already showed in my previous comments that developers have a strong (and totally legit) need for using web fonts without causing layout shifts. And in case of a strong developer need, I think we should make it easy and risk-free to use. -- GitHub Notification of comment by xiaochengh Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7271#issuecomment-1156713131 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 June 2022 16:55:33 UTC