Re: [w3ctag/design-reviews] Review request on `blocking=render` attribute for scripts, stylesheets and link resources (Issue #727)

Thanks for the review! My response is as follows:

> The explainer list a uses case of wanting to block on font loading, which can already be [controlled via CSS](https://drafts.csswg.org/css-fonts-4/#font-rendering-controls-introduction)

CSS `font-display` descriptor cannot control render-blocking. It only leaves an empty space for the text that uses the web font, and still renders other contents. Since the empty space is measured using a fallback font, its dimensions can still change when the actual web font is swapped in, causing a layout shift. There is a rich literature about this, to name a few:
- https://www.smashingmagazine.com/2021/05/reduce-font-loading-impact-css-descriptors/#wasn-t-font-display-supposed-to-solve-this

- https://simonhearne.com/2021/layout-shifts-webfonts/#why-fonts-cause-layout-shifts

- https://web.dev/optimize-cls/#web-fonts-causing-foutfoit


> The other use cases seem somewhat questionable.

I believe the other use cases are also as strong.

For the second use case (script-inserted style & script): In practice many web developers struggle to properly pre-process their blocking style sheets and scripts, which is one reason CLS is quite common. This is especially true for individual, educational or indie developers, who don't have the resources to build & maintain fancy server-side templating and serving systems. The linked educational example is one such example, which is served from raw sources without any build step, has many constituent pages, and a loader script to avoid duplication of common resources (& corresponding mistakes) across these pages. There is no advantage at all to the multi-render progressive loading for this site, it just looks jarring and ugly. `blocking=render` solves it elegantly.

For the third use case (async script), `blocking=render` provides immediate improvements to [client-side A/B testing](https://docs.google.com/presentation/d/1-cxHITwVtWJ5x3ev0__XzDtDtJn2cB9CAgN9Mkia3Ag/edit?usp=sharing). We need to ensure that the test config script (which may, e.g., restyle certain elements) is run before rendering starts. Otherwise, the user may interact with an unconfigured page, making any subsequent measurements invalid. Current approaches either manually hide the document with JS, or do nothing and risk having invalid results. Also @alexnj to elaborate.

> This feature also goes against one of the TAG's [design principles](https://w3ctag.github.io/design-principles/#avoid-render-blocking).

The principle allows adding such features “only in cases when the overall user experience is improved”, which I believe is exactly the case for `blocking=render`. In all the use cases, `blocking=render` prevents a flash of unstyled content, which the principles already deemed “undesirable”.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/727#issuecomment-1105722002

You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/727/1105722002@github.com>