Xiaocheng Hu

> That's what the current spec already does. Yeah, and it's what confused me. Maybe worths adding a note?

I think this can be closed now?

> For instance, element parsed in the parser for fragment should not be implicitly potentially render-blocking? Agreed, this shouldn't be render-blocking. The current spec is basically a translation of Blink's...

> I think an element should be render-blocking if it's parser-inserted, but should stop being render-blocking as soon as it is detached from its tree... Agreed. I originally wanted to...

> What is Chrome's existing blocking=render timeout, and would this use the same timeout? We don't have any explicit timeout currently. We just use the default network timeout -- when...

+1 to doing some JS prototyping first. > I think perhaps the less clear question if we add a property to apply the transform from an anchor, is what the...

Not a strong opinion, but I'm leaning not to add a new API if its only use case is to fullscreen the full page while something is already in the...

Should we consider the lowest common ancestor (element) of the selection start and end (with some treescope fixup when the selection spans multiple treescopes)? Or just consider the selection start?...

It's supposed to be used in [PerformanceResourceTiming](https://w3c.github.io/resource-timing/#dom-renderblockingstatustype), but the interlinks seem missing. See https://github.com/whatwg/fetch/pull/1449 and https://github.com/w3c/resource-timing/pull/327

We need to implement [preparation time document](https://html.spec.whatwg.org/multipage/scripting.html#preparation-time-document), which handles such cases.