Can script determine if window.onload has already fired?

M

Matt Kruse

There is a discussion going on in the jquery-dev mailing list that
piqued my curiosity. I'm interested to know if the smart people here
have a good answer.

Is there a cross-browser way, in script, to determine if window.onload
has already fired?

If a script is lazy loaded and needs the DOM to be ready, it can
attach to the window's load event. But if that has already fired, then
the script's code will never run. Alternatively, it can just fire its
code inline, but the DOM may not be ready.

Thoughts?

Matt Kruse
 
T

Thomas 'PointedEars' Lahn

Matt said:
There is a discussion going on in the jquery-dev mailing list that
piqued my curiosity. I'm interested to know if the smart people here
have a good answer.

Is there a cross-browser way, in script, to determine if window.onload
has already fired?

If a script is lazy loaded and needs the DOM to be ready, it can
attach to the window's load event.
Click to expand...

But it should not. The loading state of the window has nothing to do with
the loading state of the document. We've been over this.
But if that has already fired, then the script's code will never run.
Alternatively, it can just fire its code inline, but the DOM may not be
ready.

Thoughts?
Click to expand...

Smart people use the standards-compliant `onload' attribute instead.


PointedEars
 
M

Matt Kruse

But it should not.  The loading state of the window has nothing to do with
the loading state of the document.  We've been over this.
Click to expand...

Fine then, substitute in any other method you prefer.
Smart people use the standards-compliant `onload' attribute instead.
Click to expand...

Could you be more specific?

Matt Kruse
 
M

Matt Kruse

  <body onload="...">
Click to expand...

Script cannot add itself to this attribute, though.

You're steering away from the real question, anyway. Regardless of
whether you feel it should be used, is there any cross-browser way to
detect if window.onload has already fired?

Matt Kruse
 
D

David Mark

Script cannot add itself to this attribute, though.
Click to expand...

Groan. Script doesn't have to "add itself" to this attribute.
You're steering away from the real question, anyway.
Yes.

Regardless of
whether you feel it should be used, is there any cross-browser way to
detect if window.onload has already fired?
Click to expand...

Of course. Attach a load listener (or use the standard onload
attribute). They both do the same thing. One is proprietary and one
is not.

The proprietary window.onload property likely came about so that
scripts in the HEAD could set a load listener to the BODY before the
body is ready.

Now, how to know if the BODY load event has fired? Set a flag, of
course.
 
D

David Mark

[...]
If a script is lazy loaded and needs the DOM to be ready, it can
attach to the window's load event. But if that has already fired, then
the script's code will never run. Alternatively, it can just fire its
code inline, but the DOM may not be ready.
Click to expand...

And what sort of scheme are they working on where their scripts are
unclear about whether the load event has fired? Sounds like a recipe
for disaster to me.

<body onload="loaded = true;">

Or, as mentioned, set window.onload if you think that is a cooler,
more "unobtrusive" solution (despite the inherent drawbacks).
 
T

Thomas 'PointedEars' Lahn

David said:
Groan. Script doesn't have to "add itself" to this attribute.
Click to expand...

See below.
Yes.
Click to expand...

No. I was just closing at it at a slower pace :)
Of course. Attach a load listener (or use the standard onload
attribute). They both do the same thing. One is proprietary and one
is not.
Click to expand...

But if we assume that, due to the flawed concept, there are only "lazy-
loaded" scripts, there is a chicken-and-the-egg problem with adding a load
listener with scripting. Hence my recommendation to use the `onload'
attribute of the `body' element in the first place.
The proprietary window.onload property likely came about so that
scripts in the HEAD could set a load listener to the BODY before the
body is ready.
Click to expand...

Unlikely: said:
Now, how to know if the BODY load event has fired? Set a flag, of
course.
Click to expand...

That is what I was aiming at. But some people apparently need it to be
spelt to them, so thank you for that.


PointedEars
 
D

David Mark

See below.



No.  I was just closing at it at a slower pace :)
Click to expand...

I figured. I'd just as soon be done with the discussion.
But if we assume that, due to the flawed concept, there are only "lazy-
loaded" scripts, there is a chicken-and-the-egg problem with adding a load
listener with scripting.  Hence my recommendation to use the `onload'
attribute of the `body' element in the first place.
Click to expand...

Right. The whole question is silly.
Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545>
Click to expand...

I don't follow.
 
D

David Mark

If you specify an onLoad event handler for an Image object that
displays a looping GIF animation (multi-image GIF), each loop of the
animation triggers the onLoad event, and the event handler executes
once for each loop.

Is this true ?
Click to expand...

It was. Not a concern today as nobody (sane) uses animated GIF's on
the Web.
 
J

Jorge

Jorge meinte:



An onload listener for spinners which indicate loading processes? Sound
pretty recursive...
Click to expand...

LOL, yes. I've tested it and doesn't work in any (current) browser, as
Mark said.
 
M

Matt Kruse

And what sort of scheme are they working on where their scripts are
unclear about whether the load event has fired?  Sounds like a recipe
for disaster to me.
Click to expand...

Apparently some people want to lazy-load scripts (libraries, etc) that
are not needed immediately for page rendering, so they don't block and
slow down the page load. As a way of getting the UI to the user faster
and then add script for when they interact.

I'm not a big fan of doing things onload of the page, especially not
attaching critical functionality. A common jQuery recommendation is to
wrap code in $(document).ready() so it fires when the DOM is ready, at
which point you can attach event handlers, etc. I always recommend
against this approach for a number of reasons, and I rarely (if ever)
use this approach.

Nevertheless, there are many plugins and 3rd-party components that use
this approach, and if you lazy-load jQuery after window.onload has
fired then these scripts will try to attach to the event and it will
never fire.

I thought it was an interesting question, as to whether or not the
condition could be checked in script.
<body onload="loaded = true;">
Click to expand...

And this is not possible by a lazy-loaded script, which was the point
of the original question. A script retrieved and eval'd via ajax will
obviously not be able to add code to a static html tag.
Or, as mentioned, set window.onload if you think that is a cooler,
more "unobtrusive" solution (despite the inherent drawbacks).
Click to expand...

Solve the problem by turning a blind eye? :)

Matt Kruse
 
D

David Mark

Apparently some people want to lazy-load scripts (libraries, etc) that
are not needed immediately for page rendering, so they don't block and
slow down the page load. As a way of getting the UI to the user faster
and then add script for when they interact.
Click to expand...

Some people use jQuery, which is a huge hit to start with. It's a
crazy world.
I'm not a big fan of doing things onload of the page, especially not
attaching critical functionality. A common jQuery recommendation is to
wrap code in $(document).ready() so it fires when the DOM is ready, at
which point you can attach event handlers, etc. I always recommend
against this approach for a number of reasons, and I rarely (if ever)
use this approach.
Click to expand...

Seems sensible given they've been fretting that function for years and
it is known to be a bunch of hacks strung together by observation. I
read the recent exchanges and they are going down the same road to
"solve" this case.
Nevertheless, there are many plugins and 3rd-party components that use
this approach, and if you lazy-load jQuery after window.onload has
fired then these scripts will try to attach to the event and it will
never fire.
Click to expand...

Load the entire _library_ after load? The idea is completely absurd.
But a flag still works. All jQuery has to do is check the flag and
act accordingly.
I thought it was an interesting question, as to whether or not the
condition could be checked in script.


And this is not possible by a lazy-loaded script, which was the point
of the original question.
Click to expand...

You just don't get it. The flag is for the lazy loaded script.
That's how it knows that the load event for the body has fired. You
could also use window.onload or attach a load listener to the body
(assuming your script is not in the head).
A script retrieved and eval'd via ajax will
obviously not be able to add code to a static html tag.
Click to expand...

A script retrieved and eval'd via Ajax? There go all of your
perceived speed benefits. Doing that with a script like jQuery is
absurd.

And of course it could set that attribute, but that's not the point.
The point is that it won't do anything. Neither will window.onload,
which could also be set by the evaluated script. But if the evaluated
script checked a flag first or called a predetermined global function
to add "ready listeners". Last line of the loaded script would "fire"
all of them in turn if the flag is set (or call a function to do the
same thing).
Solve the problem by turning a blind eye? :)
Click to expand...

No.
 
S

Stevo

Matt said:
There is a discussion going on in the jquery-dev mailing list that
piqued my curiosity. I'm interested to know if the smart people here
have a good answer.

Is there a cross-browser way, in script, to determine if window.onload
has already fired?

If a script is lazy loaded and needs the DOM to be ready, it can
attach to the window's load event. But if that has already fired, then
the script's code will never run. Alternatively, it can just fire its
code inline, but the DOM may not be ready.

Thoughts?

Matt Kruse
Click to expand...

Shame there was no resolution to this. I was hoping for an answer to it
also. Instead of focusing on the question (the second paragraph above)
all the answers disregarded it.

I guess there is no way to find out if it's fired using regular DOM methods.
 
M

Matt Kruse

Shame there was no resolution to this. I was hoping for an answer to it
also. Instead of focusing on the question (the second paragraph above)
all the answers disregarded it.
Click to expand...

Typical of this group, which is why it's become mostly irrelevant.
I guess there is no way to find out if it's fired using regular DOM methods.
Click to expand...

It doesn't appear so.

Or to phrase it differently, a script that is executing after the
firing of window.onload has no independent way of determining that it
has already fired.

Matt Kruse
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

How to tell if the window.onload event has already fired? 6
Faster Loading through jQuery 3
News to Hackers? 17
SproutCore--over 20000 lines of new code! 49
jQuery Attribute Summit--Latest Coverage 16
David Mark's Essential Javascript Tips - Volume #8 - Tip #47E -Attaching and Detaching Event Listene 1
Ruby Weekly News 31st October - 6th November 2005 0
Ruby Weekly News 2nd - 15th May 2005 14

Members online

Total: 35 (members: 4, guests: 31)
Robots: 387

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,019
Latest member
RoxannaSta

Latest Threads

Top