Fix when a script element is implicitly potentially render-blocking

[xiaochengh]

Fixes #7893, which is a bug introduced by #7857.

• At least two implementers are interested (and none opposed):
  • Browser already behave so.
• Tests are written and can be reviewed and commented upon at:
  • For implicitly potentially render-blocking scripts: https://wpt.fyi/results/html/dom/render-blocking/parser-blocking-script.tentative.html
  • For other scripts: https://chromium-review.googlesource.com/c/chromium/src/+/3643218
• Implementation bugs are filed:
  • Browsers already behave so.

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

---

/scripting.html ( diff )

[xiaochengh]

@domenic PTAL

[domenic]

https://github.com/web-platform-tests/wpt/blob/master/html/dom/render-blocking/remove-element-unblocks-rendering.optional.html only seems to have tests for defer blocking="render" and async blocking="render", not for async and defer themselves. Are you sure this is tested?

[xiaochengh]

remove-element-unblocks-rendering.optional.html tests that the element is not render-blocking after removing the blocking=render attribute, which implies that defer and async are not implicitly render-blocking. Does it count?

And AFAIK this is a long-established and very standard behavior so if this is violated then there should be a lot of other tests failing...

[zcorpan]

No, I think a test without blocking seems necessary since the adding and removing of blocking may be handled but the absence could be implemented incorrectly.

You should link to the test if it exists. If it doesn't, please write a new test. :)

[xiaochengh]

I'm adding new tests via https://chromium-review.googlesource.com/c/chromium/src/+/3643218. PTAL

[xiaochengh]

Friendly ping...

[zcorpan]

The test looks good to me!