Define which subresources block the DOM load event

[gsnedders]

Moving this over from https://www.w3.org/Bugs/Public/show_bug.cgi?id=17011, given that's apparently appropriate nowadays.

CSS should somewhere (hence the lack of any tagged spec!) define which subresources block the load event; at least when that bug was filed IE, Firefox, and Opera blocked the load event on background images and on web fonts loading (which is therefore related to #1082), Safari and Chrome (and this is pre-fork!) didn't, blocking only on @import.

I believe someone claimed recently that Edge matches Safari and Chrome, making Firefox the odd one out. Someone should, however, test that.

[fantasai]

Agenda+ to at least solve the issue of which spec to put this in. :)

[gsnedders]

So the tests from web-platform-tests/wpt#5525 show that:

• Everything (Chrome, Edge, Firefox, Safari) delays the load event for @import
• Nothing (ditto) delays the load event for an unused @font-face

Beyond that, stuff gets less interoperable:

• Everything except Edge delays the load event for background-image and list-style-image
• Chrome and Firefox delay the load event for a used @font-face, Safari and Edge do not

[FremyCompany]

This is the bit that says we should define this:
https://html.spec.whatwg.org/#critical-subresources

Though, really, I would rather not start a discussion about what is critical or what is not. To keep our model sane and automatically up-to-date, I would argue either that any resource downloaded after applying CSS is a critical sub-resource and must be waited on (which means it must be used somewhere on the page before the load event fires otherwise it won't trigger a download), or that no subresource of css is considered critical if it isn't layout-impacting.

Based on Geoffrey's findings, Edge has the latter model (we should also delay for fonts though to be consistent) while Chrome has the former model (every subresource is critical).

Chrome's model is maybe easier to implement but it delays consequently the load event, which likely has negative perf implications.

[gsnedders]

We need some practical way to tell once all subresources to have loaded, regardless of whether this is the load event or otherwise, for the sake of WebDriver and other such testing tools, as we need to make sure there's some way to get a screenshot of a fully loaded page.

[FremyCompany]

I think you can use the resource timing api. It does require polling though, because you don't get an event when a new resource download starts.

[gsnedders]

@FremyCompany that only works in the same-origin case, though

[astearns]

RESOLVED: Add proposed DOM load events to Values & Units.