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.

[gsnedders]

Given the implications on screenshot based testing, we should let the WebDriver WG know if we decide to make it web-platform unobservable when all subresources are loaded. (Note @font-face is observable through the Font Loading API; the issue here is things like background-image.)

[domenic]

Another open question is whether indirectly-@imported stylesheets (i.e. ones that are @imported by other @imported stylesheets) count as critical subresources. Apparently browsers are not interoperable here, as pointed out by @bzbarsky in whatwg/html#3532.

I'll be defining something very tentative in HTML in whatwg/html#3544 but it would be great if the CSSWG was able to resolve this one way or another, write the tests, and move the definition into one of their specs. I'll have HTML link to this open issue.

[dbaron]

I think having behavior differences between @import and <link> (which have been described as equivalent for years) should be avoided if at all possible. (And it sounds like it's possible; it seems like the plan is that recursive @import should also block load, which I strongly support since it matches <link> and simple @import.)

Another bit that should be defined is when restrictions on use of style sheets such as media or any alternate style sheet mechanisms (title / alternate / etc., though I'm not sure what the current state of the spec is) block onload. This came up recently in a Mozilla bug pointing out lack of interop in terms of whether loading of print (or other not-currently-used-medium) style sheets blocks onload, and I think that bug pointed to a whatwg/html issue, but I can't currently find either... (I think our conclusion is that Gecko should block the load event less in those cases to match Chrome, but also that the spec should define what exactly those cases are.)

[css-meeting-bot]

The Working Group just discussed Define which subresources block the DOM load event.

The full IRC log of that discussion

<dael> Topic: Define which subresources block the DOM load event
<dael> github: https://github.com//issues/1088
<dael> TabAtkins: fantasai requested to figure out what spec it goes in
<dael> Rossen_: whatwg?
<dael> gsnedders: we resolved in values and units
<dael> TabAtkins: add proposed dom events to v&u. Okay.
<dael> fantasai: Yes. Ana added the agenda+ I don't know why.
<fantasai> s/Ana/Anne/
<dael> Rossen_: I'm okay to move on. We can come back if there's a need to reoslve.
<dael> dbaron: I think there's stuff to discuss here.
<dael> Rossen_: What would you like to discuss or does it stay in GH?
<dael> dbaron: GH may be fine. There's a bunch of non-interop but we have space to converge if we agree to try and progress in that direction. Example @import blocks if it's one level deep, but not further and other browsers never block. I think we should be consistant and not having different behavior at different depths.
<dael> dbaron: But we can discuss more on issue.
<dael> Rossen_: I think that's better.

[hiroshige-g]

Everything except Edge delays the load event for background-image

Chrome delays the load event of Document (which is tested by web-platform-tests/wpt#5525) but not the load event of the <link> element for background images.
The behavior of Firefox looks the same.

Modified @bzbarsky's test case in whatwg/html#3544:
"link loaded in" console log appears immediately, and "document loaded in" appears 4 seconds later.

<!DOCTYPE html>
<script>
  var start = performance.now();
</script>
<body
      onload="console.log('document loaded in: ' + (performance.now() - start))"
>
<div id="fox" class="fox" style="position: absolute; width: 1024px; height: 1024px;">fox</div>
<link rel="stylesheet"
      href="data:text/css,.fox{ background-image: url('http://software.hixie.ch/utilities/cgi/test-tools/delayed-file?pause=4&mime=text%2Fhtml&text=NOT+A+STYLESHEET');}"
      onload="console.log('link loaded in: ' + (performance.now() - start))"
      onerror="console.log('link errored in: ' + (performance.now() - start))">

Perhaps this is because Chrome

• Delays <link>'s load event assuming @imported are critical subresources of CSS and background-images are not, as proposed in Improve clarity in link and style sheet resource fetching whatwg/html#3544, and
• Delays Document's load event for every image loading, no matter whether the image is <img> (which is specced to delay the Document's load event in HTML spec) or background-image (I'm not aware the delay-the-Document-load-event behavior is specced anywhere - does anyone know?).

[Foxhgf]

@bw