- From: Xiaocheng Hu via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 May 2022 20:55:35 +0000
- To: public-css-archive@w3.org
Let me summarize and respond to some major concerns raised in the meeting. The biggest concern is that since render-blocking may cause the page rendering to be blocked infinitely (which is worse than anything else), we shouldn't add new render-blocking things. This is the same general concern I got when specifying "render-blocking" in the HTML spec. To resolve that, UA is allowed to unblock rendering if an internal timeout is reached, even if there are still pending render-blocking resources (scripts & style sheets). See https://html.spec.whatwg.org/C/#render-blocked So this proposal won't make the page never rendered. Nor do other render-blocking resources. --- Another point is we shouldn't make it too easy for developers to do potentially bad things (e.g., page never renders). If developers are doing workarounds/hacks to achieve that (like adding/removing `display: none` with JS), let them be; they must be very explicit when doing potentially bad things. There might also be concerns that putting things in the declarative syntax is the UA officially saying that this use case is legit and ok to do, whereas the JS hacks don't admit that. First of all, making fonts render-blocking is not an inherently bad pattern, but an alternative FCP vs. CLS tradeoff that developers want to achieve. Forcing a complicated solution is a double-edged sword that, while preventing misuse of this feature, may also lead to other suboptimal workarounds and confusions. Besides, existing JS-based workarounds (like removing `display:none` on `FontFace.load`) are not really complicated enough to prevent misusing. What is worse, such workarounds do not admit the UA-defined timeout, and would result in a strictly worse UX -- they can actually keep the page blank forever, while `font-display: critical` won't due to the UA-defined timeout. Since developers already have a strong need for this, if we ignore it and pretend it's not happening, it eventually comes at the expense of the user because the UA can't do anything about something it doesn't admit. I think it's still better if we can make legit use cases easy to achieve while having a safety net (the UA-defined timeout) against misuses (and bad network), than simply banning it. -- GitHub Notification of comment by xiaochengh Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7271#issuecomment-1130538275 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 May 2022 20:55:36 UTC