Load script when layout is known?

[Paul_Wilkins]

It’s preferable to have the menu interface working while the images are loading.

[m_hutley]

Depends on your point of view, I suppose.

I’d rather have my page fully loaded when I try and manipulate visual elements. Then again, I code on the assumption that people are in the modern world where image load times are negligible, which is a naive assumption on my part.

[Mittineague]

I don’t consider the load event “heavy”, (in my words) it’s “the HTTP response has been received”. If anything, the DOMContentloaded event would be slightly more “heavy” and is “the browser knows of all of the HTML elements”.

One thing that might “work” that would be “heavy” is to have an interval test for a getComputedStyle of something, change value(s) when needed, and then stop the interval.

I say “work” because IMHO that approach would be a dirty hack and it would be much better to correct the problem at its source.

[m3g4p0p]

Hi @5M177Y, if you want your styles and scripts to get loaded / executed in the order they appear on the page, then don’t add the defer attribute as this will cause your script to run on DOMContentLoaded (which, as you said, is not what you want). Other than that, you might wait for all styles by wrapping their load events in promises like so:

Promise.all(
  Array.from(
    document.querySelectorAll('link[rel="stylesheet"]'),
    link => new Promise((resolve, reject) => {
      link.addEventListener('load', resolve)
      link.addEventListener('error', reject)
    })
  )
).then(
  // Init stuff here
  console.log
).catch(
  // Handle errors
  console.error
)

[5M177Y]

@m3g4p0p

if you want your styles and scripts to get loaded / executed in the order they appear on the page, then don’t add the defer attribute as this will cause your script to run on DOMContentLoaded

It was totally the defer attribute causing the problems mentioned above. Thank you @m3g4p0p Annoyingly this had crossed my mind at some point, but I guess my flawed understanding put it to the back of my mind.

I thought defer was equivalent to a script tag at the end of the document (so would have been redundant in my case). So it’s actually closer to async?

Now I’m wondering if browsers are as confused as I am, and this explains the discrepancy between them.

[m3g4p0p]

@5M177Y

So it’s actually closer to async ?

Effectively it’s more like wrapping your code in an DOMContentReady callback – see here for details. As it is also stated there, the exact behaviour is a rather complex matter though.

[5M177Y]

I guess the bit that’s not clear about that is, I wouldn’t have expected wrapping code in DOMContentReady to cause it to run sooner. This is why I mentioned async, and I guess this might be where the complexities come in, but it seems to me that, in Firefox at least, using defer (without async) causes the file to load asynchronously, on DOMContentReady, hence the possibility of it running before the the CSS file is loaded.

[SamuelCalifornia]

I don’t see anyone mentioning the affect of JavaScript and frames can have on this.

I have never researched frames extensively but (based on my memory) the DOM content load event handler or some related event handler has an option that determines whether the event handler processes frames. Frames can have a totally different HTML document. I think there are events for frame loading.

Scripts can make things much more complicated. Websites often add and/or update the DOM. Typically when that happens the browser will fire another document download event and a corresponding document complete. I forget the details of what the specific events are. So I hear you asking how to know when the document is actually complete. That can be complicated. As far as I know the only way to know is analyze the document and determine a solution unique to that document.