Add the render-blocking mechanism and blocking=render attribute

[xiaochengh]

For #7131

• At least two implementers are interested (and none opposed):
  • Chrome
  • Firefox seems interested per blocking="render" attribute on <link>, <script> and <style> mozilla/standards-positions#608 and triage call engagement
• Tests are written and can be reviewed and commented upon at:
  • html/dom/render-blocking
• Implementation bugs are filed:
  • Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1271296
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1751383
  • Safari: …

(See WHATWG Working Mode: Changes for more details.)

---

/dom.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/links.html ( diff )
/parsing.html ( diff )
/scripting.html ( diff )
/semantics.html ( diff )
/urls-and-fetching.html ( diff )
/webappapis.html ( diff )

[xiaochengh]

@domenic

[domenic]

This looks really good. I cannot find any problems with the normative mechanisms; they are very nice and rigorously specified. All that remains is tightening up the attribute definition and some nits.

[xiaochengh]

Thanks for the very detailed review!

I also added handling for the style element.

[smaug----]

Since blocking is allowed to not happen (there is word "should" mentioned, tough that is lowercase in the pr) and I expect browsers will have some timer or such to ensure the page isn't unrendered forever (since I assume the previous page is often shown until the next page can be rendered, and we don't want the old page to render forever) should there be some event hinting that render blocking didn't succeed or was cancelled by the UA? Another option would be to tweak the naming a bit so that the attribute can be thought as a hint to UA.

[xiaochengh]

I think it's already implied that the UA won't be blocked forever. The Fetch spec allows a fetch group to be terminated, and then this PR unblocks rendering. So UA may use an internal timeout for any fetch (which I believe is what all current browsers do), and then unblocks rendering after the render-blocking resources time out.

I will add a note for that.

[domenic]

Well, is the intent that we only unblock rendering if the fetch times out (and thus the resource never loads successfully)? I thought there was going to be an allowance for a lower implementation-defined timeout, like, "the user has been staring at a blank screen for 10 seconds, but I'm pretty sure we can draw something more useful based on what's downloaded so far, so let's start having rendering opportunities now regardless of the blocking elements".

[xiaochengh]

Well, is the intent that we only unblock rendering if the fetch times out (and thus the resource never loads successfully)?

For the current MVP, yes.

We've thought about this in the proposal, and may allow setting an explicit timeout or other criteria to unblock in a future version.

[domenic]

Hmm OK, I'm unsure which understanding the Gecko folks had; I thought there was going to be a separate implementation-defined timeout for rendering opportunities in the spec. (And there still could be, if other browsers want one; it's just Chrome might set their value to infinite.) Let's see what they say.

In the meantime I'll do the review for the style element parts.

[domenic]

Style stuff looks great.

[xiaochengh]

Thanks for the review! Before merging:

• I just recalled that we should make parser-inserted <link rel=stylesheet> implicitly render-blocking to match the behavior of all current browsers. Should I add it into this PR or a followup PR?
• How do we get another implementer's interest?
• Do we need to add WPT before merging this PR?

[domenic]

I just recalled that we should make parser-inserted <link rel=stylesheet> implicitly render-blocking to match the behavior of all current browsers. Should I add it into this PR or a followup PR?

In this PR seems like a good idea.

How do we get another implementer's interest?

We can ask @annevk and @smaug---- to chime in here from Mozilla, and/or file an issue on https://github.com/mozilla/standards-positions/ . Similarly, for Apple, we can ask @hober for her thoughts, or email webkit-dev. (Official position requests are required as part of the Chromium shipping process anyway, so it's a good idea.)

Note that may lead to additional feedback; it's not just a binary yes/no on the current proposal!

Do we need to add WPT before merging this PR?

Yes.

[xiaochengh]

Alright, I've sent requests for position to mozilla/standards-positions and webkit-dev

[smaug----]

I think it's already implied that the UA won't be blocked forever. The Fetch spec allows a fetch group to be terminated, and then this PR unblocks rendering. So UA may use an internal timeout for any fetch (which I believe is what all current browsers do), and then unblocks rendering after the render-blocking resources time out.

I wasn't talking about fetch timeout. A request may just take a lot of time to succeed. And since the page may have started to run scripts at that point, it would be worrisome for the UA to show the previous page. And if previous page wasn't shown, something else needs to be painted. An all white page is one option, but I'd rather paint whatever is already there in the page
(there might be for example <html style="background-color: #my-fancy-background-color;")

[xiaochengh]

I see. This might be out of the scope of the current MVP, though, which just tries to extend the already existing render-blocking behavior for stylesheets.

IIUC in a previous meeting we've discussed the idea of painting something first, then blocking rendering for the critical resources, then resuming rendering after they are loaded. But this is a whole new mechanism, which I think is out of the scope of the current proposal & PR.

[domenic]

This might be out of the scope of the current MVP, though, which just tries to extend the already existing render-blocking behavior for stylesheets.

It really doesn't feel like that big of an extension. As I noted in the review above, it's about one extra sentence. And Chromium can just not implement that (i.e., set their implementation-defined timeout to infinite). IMO we should do it.

[xiaochengh]

Ah, looks like I misunderstood @smaug----'s comment. Now I understand it as "if the render-blocking resources take too long, just unblock rendering", in which case we can just add that sentence as in @domenic's review

[xiaochengh]

Updated:

• Added an implementation-defined timeout to allow unblocking rendering early
• Made parser-inserted <link rel=stylesheet> implicitly render-blocking
• Changed callers of unblock rendering algorithm not to check whether the element is render-blocking, because this is unnecessary and makes unblocking on implicitly render-blocking stylesheets more complicated

[domenic]

LGTM with nits.