Fwiw the spec is already written to allow this. On Wed, 12 Mar 2025 at 02:35, Jiacheng Guo <g...@google.com> wrote:
> I have checked with @Vladimir Levin <vmp...@google.com>. Currently chrome > is not supporting inserting any kind of render-blocking elements from > javascript. Since it is a very practical use case we may work on adding the > support. > > On Tue, Mar 11, 2025 at 2:19 PM Jiacheng Guo <g...@google.com> wrote: > >> Sorry I may have some misunderstanding on the current implementation of >> render-blocking elements when it comes to scripts. I'll discuss further >> with the team and be back with the conclusion. >> >> On Tue, Mar 11, 2025 at 11:25 AM Jiacheng Guo <g...@google.com> wrote: >> >>> 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/CAJ5xic-CfHBeqMPjJXcMGrpdWprvcx573eg91kv%2B5SkEDaCTYw%40mail.gmail.com.
