Can script determine if window.onload has already fired?

11/19/09, 17:55

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

11/19/09, 18:30

Matt Kruse wrote:

> 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 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?

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

PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

11/19/09, 18:35

On Nov 19, 12:30pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> 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.

Fine then, substitute in any other method you prefer.

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

Could you be more specific?

Matt Kruse

11/19/09, 19:06

Matt Kruse wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Smart people use the standards-compliant `onload' attribute instead.
>
> Could you be more specific?

<body onload="...">

PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

11/19/09, 20:07

On Nov 19, 1:06pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> <body onload="...">

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

11/19/09, 21:54

On Nov 19, 3:07pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Nov 19, 1:06pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>
> > <body onload="...">
>
> Script cannot add itself to this attribute, though.

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?

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.

11/19/09, 22:00

On Nov 19, 12:55pm, Matt Kruse <m...@thekrusefamily.com> wrote:

[...]

>
> 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.
>

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).

11/19/09, 22:47

On Nov 19, 5:34pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> David Mark wrote:
> > On Nov 19, 3:07 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> >> On Nov 19, 1:06 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> >> wrote:
> >> > <body onload="...">
>
> >> Script cannot add itself to this attribute, though.
>
> > Groan. Script doesn't have to "add itself" to this attribute.
>
> See below.
>
> >> You're steering away from the real question, anyway.
>
> > Yes.
>
> No. I was just closing at it at a slower pace

I figured. I'd just as soon be done with the discussion.

>
> >> Regardless of
> >> whether you feel it should be used, is there any cross-browser way to
> >> detect if window.onload has already fired?
>
> > 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.
>
> 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.

Right. The whole question is silly.

>
> > 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.
>
> Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545>

I don't follow.

11/19/09, 22:54

On Nov 19, 11:34pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
>
> Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545>

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 ?
--
Jorge.

11/19/09, 23:01

On Nov 19, 5:54pm, Jorge <jo...@jorgechamorro.com> wrote:
> On Nov 19, 11:34pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>
>
>
> > Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545>
>
> 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 ?

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

11/19/09, 23:09

On Nov 20, 12:01am, David Mark <dmark.cins...@gmail.com> wrote:
> On Nov 19, 5:54pm, Jorge <jo...@jorgechamorro.com> wrote:
>
> > On Nov 19, 11:34pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> > wrote:
>
> > > Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545>
>
> > 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 ?
>
> It was. Not a concern today as nobody (sane) uses animated GIF's on
> the Web.

Not even spinners ?
--
Jorge.

11/19/09, 23:16

David Mark wrote:

> Thomas 'PointedEars' Lahn wrote:
>> David Mark wrote:
>> > 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.
>>
>> Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545>
>
> I don't follow.

There is no mentioning of setting a listener to the BODY with window.onload
there.

PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

11/19/09, 23:23

Jorge meinte:
> On Nov 20, 12:01 am, David Mark <dmark.cins...@gmail.com> wrote:

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

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

Gregor

--
http://www.gregorkofler.com

11/19/09, 23:37

On Nov 20, 12:23am, Gregor Kofler <use...@gregorkofler.com> wrote:
> Jorge meinte:
>
> > On Nov 20, 12:01 am, David Mark <dmark.cins...@gmail.com> wrote:
> >> It was. Not a concern today as nobody (sane) uses animated GIF's on
> >> the Web.
>
> > Not even spinners ?
>
> An onload listener for spinners which indicate loading processes? Sound
> pretty recursive...

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

11/19/09, 23:45

On Nov 19, 6:09pm, Jorge <jo...@jorgechamorro.com> wrote:
> On Nov 20, 12:01am, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
> > On Nov 19, 5:54pm, Jorge <jo...@jorgechamorro.com> wrote:
>
> > > On Nov 19, 11:34pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> > > wrote:
>
> > > > Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545>
>
> > > 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 ?
>
> > It was. Not a concern today as nobody (sane) uses animated GIF's on
> > the Web.
>
> Not even spinners ?

Certainly not paired with an onload listener.

And I think the
onload firing on-loop issue is only in ancient browsers.

11/20/09, 02:05

On Nov 19, 4:00pm, David Mark <dmark.cins...@gmail.com> wrote:
> 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.

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;">

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).

Solve the problem by turning a blind eye?

Matt Kruse

11/20/09, 02:27

On Nov 19, 9:05pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Nov 19, 4:00pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > 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.
>
> 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.

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.

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.

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.
>
> > <body onload="loaded = true;">
>
> And this is not possible by a lazy-loaded script, which was the point
> of the original question.

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.

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).

>
> > Or, as mentioned, set window.onload if you think that is a cooler,
> > more "unobtrusive" solution (despite the inherent drawbacks).
>
> Solve the problem by turning a blind eye?

No.

11/23/09, 19:46

Matt Kruse wrote:
> 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

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.

11/23/09, 20:51

On Nov 23, 1:46pm, Stevo <n...@mail.invalid> wrote:
> 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.

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.

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

11/23/09, 23:07

Matt Kruse wrote:
> On Nov 23, 1:46 pm, Stevo <n...@mail.invalid> wrote:
>> 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.
>
> Typical of this group, which is why it's become mostly irrelevant.

Maybe for you but not for me.

Andrew Poulos

11/24/09, 00:48

On Nov 24, 5:46am, Stevo <n...@mail.invalid> wrote:
> Matt Kruse wrote:
> > 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
>
> Shame there was no resolution to this.

There was a resolution.

> I was hoping for an answer to it
> also.

There was.

> Instead of focusing on the question (the second paragraph above)
> all the answers disregarded it.

There were two answers that focussed specifically on the question and
provided two approaches.

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

You got it, but that wasn't the question. There was no specific
mention of a DOM method, but that doesn't mean there aren't strategies
for determining if it's occurred.

--
Rob

11/24/09, 02:15

Matt Kruse wrote:
> On Nov 23, 1:46pm, Stevo <n...@mail.invalid> wrote:
> > 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.
>
> Typical of this group, which is why it's become mostly irrelevant.

Typical of your petulance and incompetence, you can't see the forest
for the trees. Clearly you came into this fact-finding mission with a
negative attitude (as usual).

>
> > I guess there is no way to find out if it's fired using regular DOM methods.
>
> It doesn't appear so.

Then you are blind. There must be some script that downloads the
secondary code. So that script sets an onload listener that sets a
"loaded" flag. The other scripts refer to that flag. End of story.

>
> 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.

No kidding. You should have put it that way to start with.

11/24/09, 04:12

On Nov 23, 8:15pm, David Mark <dmark.cins...@gmail.com> wrote:
> Then you are blind. There must be some script that downloads the
> secondary code. So that script sets an onload listener that sets a
> "loaded" flag. The other scripts refer to that flag. End of story.

1) That depends on the first script setting an onload listener. What
if it is loaded after window.onload?

2) This strategy assumes you can modify the source of the second
script.

Matt Kruse

11/24/09, 05:38

Matt Kruse wrote:
> On Nov 23, 8:15 pm, David Mark <dmark.cins...@gmail.com> wrote:
>> Then you are blind. There must be some script that downloads the
>> secondary code. So that script sets an onload listener that sets a
>> "loaded" flag. The other scripts refer to that flag. End of story.
>
> 1) That depends on the first script setting an onload listener. What
> if it is loaded after window.onload?
>
> 2) This strategy assumes you can modify the source of the second
> script.
>
> Matt Kruse

All it would take is for the browser to set window.onload = true after
it's called all registered onload handlers, and those of us who want to
know if it's already happened can check if(window.onload === true). I
wish one of them would take the lead.

The DOMContentLoaded event was a start in a related direction, but still
we have no simple properties that let script determine whether onload
has triggered, and/or whether the DOM is ready for full scripting.

To further explain what Matt and I are both looking for, here's an example.

Site A decides to load library script B at some point during the viewing
of a page. It's completely unknown when this might be. They might be
doing it in the head section, in the body section, or on-demand well
after the onload event has fired because of some user action.

Script B wants to know into which page state it's being loaded. Whether
or not the event has fired already.

Question: How can script B know if onload has fired without putting
demands on site A to have to set flags (because the browser itself
doesn't seem to want to).

11/24/09, 06:02

On Nov 23, 11:12pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Nov 23, 8:15pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Then you are blind. There must be some script that downloads the
> > secondary code. So that script sets an onload listener that sets a
> > "loaded" flag. The other scripts refer to that flag. End of story..
>
> 1) That depends on the first script setting an onload listener. What
> if it is loaded after window.onload?

And, pray tell, what would have loaded it after onload? Whatever
script actually does the loading by XHR/eval must set the onload
listener. If you don't know how to set an onload listener before
load, you've got much bigger problems.

>
> 2) This strategy assumes you can modify the source of the second
> script.

Again, no kidding. You think you are going to load any old script
after load and have it work like magic? How was it going to answer
your question (detecting onload having fired) if you didn't modify it
to do so?

11/19/09, 18:30	#2
Thomas 'PointedEars' Lahn Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? Matt Kruse wrote: > 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 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? Smart people use the standards-compliant `onload' attribute instead. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

11/19/09, 18:35	#3
Matt Kruse Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? On Nov 19, 12:30pm, Thomas 'PointedEars' Lahn <PointedE...@web.de> wrote: > 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. Fine then, substitute in any other method you prefer. > Smart people use the standards-compliant `onload' attribute instead. Could you be more specific? Matt Kruse

11/19/09, 19:06	#4
Thomas 'PointedEars' Lahn Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? Matt Kruse wrote: > Thomas 'PointedEars' Lahn wrote: >> Smart people use the standards-compliant `onload' attribute instead. > > Could you be more specific? <body onload="..."> PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann

11/19/09, 20:07	#5
Matt Kruse Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? On Nov 19, 1:06pm, Thomas 'PointedEars' Lahn <PointedE...@web.de> wrote: > <body onload="..."> 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

11/19/09, 21:54	#6
David Mark Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? On Nov 19, 3:07pm, Matt Kruse <m...@thekrusefamily.com> wrote: > On Nov 19, 1:06pm, Thomas 'PointedEars' Lahn <PointedE...@web.de> > wrote: > > > <body onload="..."> > > Script cannot add itself to this attribute, though. 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? 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.

11/19/09, 17:55	#1
Matt Kruse Posts: n/a Hébergeur:	Can script determine if window.onload has already fired? 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

11/19/09, 22:00	#7
David Mark Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? On Nov 19, 12:55pm, Matt Kruse <m...@thekrusefamily.com> wrote: [...] > > 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. > 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).

11/19/09, 22:47	#8
David Mark Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? On Nov 19, 5:34pm, Thomas 'PointedEars' Lahn <PointedE...@web.de> wrote: > David Mark wrote: > > On Nov 19, 3:07 pm, Matt Kruse <m...@thekrusefamily.com> wrote: > >> On Nov 19, 1:06 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de> > >> wrote: > >> > <body onload="..."> > > >> Script cannot add itself to this attribute, though. > > > Groan. Script doesn't have to "add itself" to this attribute. > > See below. > > >> You're steering away from the real question, anyway. > > > Yes. > > No. I was just closing at it at a slower pace I figured. I'd just as soon be done with the discussion. > > >> Regardless of > >> whether you feel it should be used, is there any cross-browser way to > >> detect if window.onload has already fired? > > > 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. > > 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. Right. The whole question is silly. > > > 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. > > Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545> I don't follow.

11/19/09, 22:54	#9
Jorge Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? On Nov 19, 11:34pm, Thomas 'PointedEars' Lahn <PointedE...@web.de> wrote: > > Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545> 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 ? -- Jorge.

11/19/09, 23:01	#10
David Mark Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? On Nov 19, 5:54pm, Jorge <jo...@jorgechamorro.com> wrote: > On Nov 19, 11:34pm, Thomas 'PointedEars' Lahn <PointedE...@web.de> > wrote: > > > > > Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545> > > 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 ? It was. Not a concern today as nobody (sane) uses animated GIF's on the Web.

11/19/09, 23:09	#11
Jorge Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? On Nov 20, 12:01am, David Mark <dmark.cins...@gmail.com> wrote: > On Nov 19, 5:54pm, Jorge <jo...@jorgechamorro.com> wrote: > > > On Nov 19, 11:34pm, Thomas 'PointedEars' Lahn <PointedE...@web.de> > > wrote: > > > > Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545> > > > 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 ? > > It was. Not a concern today as nobody (sane) uses animated GIF's on > the Web. Not even spinners ? -- Jorge.

11/19/09, 23:16	#12
Thomas 'PointedEars' Lahn Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? David Mark wrote: > Thomas 'PointedEars' Lahn wrote: >> David Mark wrote: >> > 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. >> >> Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545> > > I don't follow. There is no mentioning of setting a listener to the BODY with window.onload there. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

11/19/09, 23:23	#13
Gregor Kofler Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? Jorge meinte: > On Nov 20, 12:01 am, David Mark <dmark.cins...@gmail.com> wrote: >> It was. Not a concern today as nobody (sane) uses animated GIF's on >> the Web. > > Not even spinners ? An onload listener for spinners which indicate loading processes? Sound pretty recursive... Gregor -- http://www.gregorkofler.com

11/19/09, 23:37	#14
Jorge Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? On Nov 20, 12:23am, Gregor Kofler <use...@gregorkofler.com> wrote: > Jorge meinte: > > > On Nov 20, 12:01 am, David Mark <dmark.cins...@gmail.com> wrote: > >> It was. Not a concern today as nobody (sane) uses animated GIF's on > >> the Web. > > > Not even spinners ? > > An onload listener for spinners which indicate loading processes? Sound > pretty recursive... LOL, yes. I've tested it and doesn't work in any (current) browser, as Mark said. -- Jorge.

11/19/09, 23:45	#15
David Mark Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? On Nov 19, 6:09pm, Jorge <jo...@jorgechamorro.com> wrote: > On Nov 20, 12:01am, David Mark <dmark.cins...@gmail.com> wrote: > > > > > On Nov 19, 5:54pm, Jorge <jo...@jorgechamorro.com> wrote: > > > > On Nov 19, 11:34pm, Thomas 'PointedEars' Lahn <PointedE...@web.de> > > > wrote: > > > > > Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545> > > > > 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 ? > > > It was. Not a concern today as nobody (sane) uses animated GIF's on > > the Web. > > Not even spinners ? Certainly not paired with an onload listener. And I think the onload firing on-loop issue is only in ancient browsers.

11/20/09, 02:05	#16
Matt Kruse Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? On Nov 19, 4:00pm, David Mark <dmark.cins...@gmail.com> wrote: > 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. 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;"> 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). Solve the problem by turning a blind eye? Matt Kruse

11/20/09, 02:27	#17
David Mark Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? On Nov 19, 9:05pm, Matt Kruse <m...@thekrusefamily.com> wrote: > On Nov 19, 4:00pm, David Mark <dmark.cins...@gmail.com> wrote: > > > 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. > > 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. 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. 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. 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. > > > <body onload="loaded = true;"> > > And this is not possible by a lazy-loaded script, which was the point > of the original question. 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. 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). > > > Or, as mentioned, set window.onload if you think that is a cooler, > > more "unobtrusive" solution (despite the inherent drawbacks). > > Solve the problem by turning a blind eye? No.

11/23/09, 19:46	#18
Stevo Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? Matt Kruse wrote: > 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 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.

11/23/09, 20:51	#19
Matt Kruse Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? On Nov 23, 1:46pm, Stevo <n...@mail.invalid> wrote: > 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. 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. 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

11/23/09, 23:07	#20
Andrew Poulos Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? Matt Kruse wrote: > On Nov 23, 1:46 pm, Stevo <n...@mail.invalid> wrote: >> 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. > > Typical of this group, which is why it's become mostly irrelevant. Maybe for you but not for me. Andrew Poulos

11/24/09, 00:48	#21
RobG Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? On Nov 24, 5:46am, Stevo <n...@mail.invalid> wrote: > Matt Kruse wrote: > > 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 > > Shame there was no resolution to this. There was a resolution. > I was hoping for an answer to it > also. There was. > Instead of focusing on the question (the second paragraph above) > all the answers disregarded it. There were two answers that focussed specifically on the question and provided two approaches. > I guess there is no way to find out if it's fired using regular DOM methods. You got it, but that wasn't the question. There was no specific mention of a DOM method, but that doesn't mean there aren't strategies for determining if it's occurred. -- Rob

11/24/09, 02:15	#22
David Mark Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? Matt Kruse wrote: > On Nov 23, 1:46pm, Stevo <n...@mail.invalid> wrote: > > 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. > > Typical of this group, which is why it's become mostly irrelevant. Typical of your petulance and incompetence, you can't see the forest for the trees. Clearly you came into this fact-finding mission with a negative attitude (as usual). > > > I guess there is no way to find out if it's fired using regular DOM methods. > > It doesn't appear so. Then you are blind. There must be some script that downloads the secondary code. So that script sets an onload listener that sets a "loaded" flag. The other scripts refer to that flag. End of story. > > 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. No kidding. You should have put it that way to start with.

11/24/09, 04:12	#23
Matt Kruse Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? On Nov 23, 8:15pm, David Mark <dmark.cins...@gmail.com> wrote: > Then you are blind. There must be some script that downloads the > secondary code. So that script sets an onload listener that sets a > "loaded" flag. The other scripts refer to that flag. End of story. 1) That depends on the first script setting an onload listener. What if it is loaded after window.onload? 2) This strategy assumes you can modify the source of the second script. Matt Kruse

11/24/09, 05:38	#24
Stevo Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? Matt Kruse wrote: > On Nov 23, 8:15 pm, David Mark <dmark.cins...@gmail.com> wrote: >> Then you are blind. There must be some script that downloads the >> secondary code. So that script sets an onload listener that sets a >> "loaded" flag. The other scripts refer to that flag. End of story. > > 1) That depends on the first script setting an onload listener. What > if it is loaded after window.onload? > > 2) This strategy assumes you can modify the source of the second > script. > > Matt Kruse All it would take is for the browser to set window.onload = true after it's called all registered onload handlers, and those of us who want to know if it's already happened can check if(window.onload === true). I wish one of them would take the lead. The DOMContentLoaded event was a start in a related direction, but still we have no simple properties that let script determine whether onload has triggered, and/or whether the DOM is ready for full scripting. To further explain what Matt and I are both looking for, here's an example. Site A decides to load library script B at some point during the viewing of a page. It's completely unknown when this might be. They might be doing it in the head section, in the body section, or on-demand well after the onload event has fired because of some user action. Script B wants to know into which page state it's being loaded. Whether or not the event has fired already. Question: How can script B know if onload has fired without putting demands on site A to have to set flags (because the browser itself doesn't seem to want to).

11/24/09, 06:02	#25
David Mark Posts: n/a Hébergeur:	Re: Can script determine if window.onload has already fired? On Nov 23, 11:12pm, Matt Kruse <m...@thekrusefamily.com> wrote: > On Nov 23, 8:15pm, David Mark <dmark.cins...@gmail.com> wrote: > > > Then you are blind. There must be some script that downloads the > > secondary code. So that script sets an onload listener that sets a > > "loaded" flag. The other scripts refer to that flag. End of story.. > > 1) That depends on the first script setting an onload listener. What > if it is loaded after window.onload? And, pray tell, what would have loaded it after onload? Whatever script actually does the loading by XHR/eval must set the onload listener. If you don't know how to set an onload listener before load, you've got much bigger problems. > > 2) This strategy assumes you can modify the source of the second > script. Again, no kidding. You think you are going to load any old script after load and have it work like magic? How was it going to answer your question (detecting onload having fired) if you didn't modify it to do so?