Yes, the design and the implementation allows the critical content elements to be added via JS as well. I'll update the chromestatus and the explainer to include this use case as well.
On Mon, Mar 10, 2025 at 6:06 PM Jake Archibald <jaffathec...@gmail.com> wrote: > On Wednesday, 5 March 2025 at 05:23:20 UTC Chromestatus wrote: > > Contact emails g...@google.com > > Explainer https://github.com/whatwg/html/issues/11070 > > Specification None > > Summary > > We propose to add a new render blocking token full-frame-rate to the > blocking attributes. When the renderer is blocked with the full-frame-rate > token, the renderer will work at a lower frame rate so as to reserve more > resources for loading. An example use case of the proposed API will be: The > web page contains an element <link rel="expect" href="#critical-content" > blocking="full-frame-rate"/> in the page head. After parsing this element, > the renderer will work at an implementation-specific lower frame rate. > After the #critical-content element is parsed, the renderer will restore > its frame rate. > > Maybe this is already the intent, but this should work in the same way > as <link rel="expect" href="#critical-content" blocking="render"/>. As in, > detecting #critical-content shouldn't be limited to the HTML parser (but > yes, the element must not be in the parser's stack of open elements). > > The allows cases where #critical-content is added via JS. > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJQw1NytFihFxUPZdSF%2Bhu17fSqxffx-P1Ae8tyTZ1ZnX2p2QA%40mail.gmail.com.
