Can script determine if window.onload has already fired?
in [JavaScript]
|
From: David Mark on 19 Nov 2009 18:45 On Nov 19, 6:09 pm, Jorge <jo...(a)jorgechamorro.com> wrote: > On Nov 20, 12:01 am, David Mark <dmark.cins...(a)gmail.com> wrote: > > > > > On Nov 19, 5:54 pm, Jorge <jo...(a)jorgechamorro.com> wrote: > > > > On Nov 19, 11:34 pm, Thomas 'PointedEars' Lahn <PointedE...(a)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.
From: Matt Kruse on 19 Nov 2009 21:05 On Nov 19, 4:00 pm, David Mark <dmark.cins...(a)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
From: David Mark on 19 Nov 2009 21:27 On Nov 19, 9:05 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote: > On Nov 19, 4:00 pm, David Mark <dmark.cins...(a)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.
From: Stevo on 23 Nov 2009 14: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.
From: Matt Kruse on 23 Nov 2009 15:51
On Nov 23, 1:46 pm, Stevo <n...(a)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 |