New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define which subresources block the DOM load event #1088

Open
gsnedders opened this Issue Mar 8, 2017 · 12 comments

Comments

Projects
None yet
9 participants
@gsnedders
Copy link
Contributor

gsnedders commented Mar 8, 2017

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 fantasai added the Agenda+ label Mar 30, 2017

@fantasai

This comment has been minimized.

Copy link
Contributor

fantasai commented Mar 30, 2017

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

@gsnedders

This comment has been minimized.

Copy link
Contributor Author

gsnedders commented Apr 10, 2017

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 comment has been minimized.

Copy link
Contributor

FremyCompany commented Apr 12, 2017

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

This comment has been minimized.

Copy link
Contributor Author

gsnedders commented Apr 12, 2017

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

This comment has been minimized.

Copy link
Contributor

FremyCompany commented Apr 12, 2017

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

This comment has been minimized.

Copy link
Contributor Author

gsnedders commented Apr 12, 2017

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

@astearns astearns removed the Agenda+ F2F label Apr 18, 2017

@astearns

This comment has been minimized.

Copy link
Member

astearns commented Apr 18, 2017

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

@gsnedders

This comment has been minimized.

Copy link
Contributor Author

gsnedders commented Jul 1, 2017

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

This comment has been minimized.

Copy link
Collaborator

domenic commented Apr 4, 2018

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

This comment has been minimized.

Copy link
Member

dbaron commented Apr 25, 2018

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

This comment has been minimized.

Copy link
Member

css-meeting-bot commented May 2, 2018

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

This comment has been minimized.

Copy link

hiroshige-g commented Oct 4, 2018

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 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?).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment