DOM ready, window.onload, etc.
in [JavaScript]
|
Prev: FAQ Topic - Why do I get permission denied when accessing a frame/window? (2009-12-27)
Next: Best Performance Javascript on IE6 for finding top and left using offsetTop and offsetLeft
From: Hans-Georg Michna on 28 Dec 2009 08:55 Hi everybody; hope you all got over Xmas in good shape. The following may be a frequently asked question, but I haven't seen any inspiring answer. Does anybody here have a good idea or some simple working code to solve the problem of having JavaScript code work on the DOM just after it is loaded? window.onload has the obvious problem that it waits for inessential content like images and can therefore be very late. Resig & Co. have a working method in jQuery, but it relies on browser sniffing and several browser-specific ways. Obviously this is not guaranteed to work in future browsers and may need regular updates. I am particularly looking for a method that can be done only in JavaScript, without having to have any dedicated HTML code embedded in documents. It seems that there can be no perfection here, so a method that works in 99% of all cases will have to be good enough. I'm thinking along the lines of checking the document body and waiting until it is stable for a short time like a second. Not a heavenly solution, but at least totally browser-independent. I have already tried to append a tiny child node inside the body and then checking one of its rendering parameters, but the method will probably have to be refined, for example by checking that no new elements are added after it because the DOM is still being built up. How about checking some parameter of the document body in regular, relatively slow intervals, like the total number of nodes or some such? Browsers that allow JavaScript to access the DOM before it is completely built should yield a rising, then stabilizing number. Or perhaps the identity of the last node could be checked, assuming that the DOM is always built sequentially from HTML code. I need to do this only for web pages over which I have at least some control and whose HTML structure I know. Of course the JavaScript code should at the same time wait for window.onload as a last resort. Not sure if this is possible in any decent quality at all, but I'd like to give it a try if I see a chance. Hans-Georg
From: JR on 28 Dec 2009 17:00 On Dec 28, 11:55 am, Hans-Georg Michna <hans- georgNoEmailPle...(a)michna.com> wrote: > Hi everybody; hope you all got over Xmas in good shape. > > The following may be a frequently asked question, but I haven't > seen any inspiring answer. I didn't find any entry about that in the c.l.js FAQ. > Does anybody here have a good idea or some simple working code > to solve the problem of having JavaScript code work on the DOM > just after it is loaded? window.onload has the obvious problem > that it waits for inessential content like images and can > therefore be very late. > > Resig & Co. have a working method in jQuery, but it relies on > browser sniffing and several browser-specific ways. Obviously > this is not guaranteed to work in future browsers and may need > regular updates. > > I am particularly looking for a method that can be done only in > JavaScript, without having to have any dedicated HTML code > embedded in documents. > > It seems that there can be no perfection here, so a method that > works in 99% of all cases will have to be good enough. > > I'm thinking along the lines of checking the document body and > waiting until it is stable for a short time like a second. Not a > heavenly solution, but at least totally browser-independent. > > I have already tried to append a tiny child node inside the body > and then checking one of its rendering parameters, but the > method will probably have to be refined, for example by checking > that no new elements are added after it because the DOM is still > being built up. > > How about checking some parameter of the document body in > regular, relatively slow intervals, like the total number of > nodes or some such? Browsers that allow JavaScript to access the > DOM before it is completely built should yield a rising, then > stabilizing number. Or perhaps the identity of the last node > could be checked, assuming that the DOM is always built > sequentially from HTML code. I need to do this only for web > pages over which I have at least some control and whose HTML > structure I know. > > Of course the JavaScript code should at the same time wait for > window.onload as a last resort. > > Not sure if this is possible in any decent quality at all, but > I'd like to give it a try if I see a chance. Dean Edwards addressed the 'window.onload' problem in his [we]blog: http://dean.edwards.name/weblog/2005/09/busted/ http://dean.edwards.name/weblog/2006/06/again/ But his 'solution' is still incomplete - it covers only IE, Safari and Firefox (versions available in 2006). Yahoo has the 'onDOMReady' method: http://developer.yahoo.com/yui/event/#ondomready Cheers, JR
From: David Mark on 28 Dec 2009 19:20 On Dec 28, 5:00 pm, JR <groups_j...(a)yahoo.com.br> wrote: > On Dec 28, 11:55 am, Hans-Georg Michna <hans- > > georgNoEmailPle...(a)michna.com> wrote: > > Hi everybody; hope you all got over Xmas in good shape. > > > The following may be a frequently asked question, but I haven't > > seen any inspiring answer. > > I didn't find any entry about that in the c.l.js FAQ. There isn't one. > > > > > Does anybody here have a good idea or some simple working code > > to solve the problem of having JavaScript code work on the DOM > > just after it is loaded? window.onload has the obvious problem > > that it waits for inessential content like images and can > > therefore be very late. > > > Resig & Co. have a working method in jQuery, but it relies on > > browser sniffing and several browser-specific ways. Obviously > > this is not guaranteed to work in future browsers and may need > > regular updates. > > > I am particularly looking for a method that can be done only in > > JavaScript, without having to have any dedicated HTML code > > embedded in documents. > > > It seems that there can be no perfection here, so a method that > > works in 99% of all cases will have to be good enough. > > > I'm thinking along the lines of checking the document body and > > waiting until it is stable for a short time like a second. Not a > > heavenly solution, but at least totally browser-independent. > > > I have already tried to append a tiny child node inside the body > > and then checking one of its rendering parameters, but the > > method will probably have to be refined, for example by checking > > that no new elements are added after it because the DOM is still > > being built up. > > > How about checking some parameter of the document body in > > regular, relatively slow intervals, like the total number of > > nodes or some such? Browsers that allow JavaScript to access the > > DOM before it is completely built should yield a rising, then > > stabilizing number. Or perhaps the identity of the last node > > could be checked, assuming that the DOM is always built > > sequentially from HTML code. I need to do this only for web > > pages over which I have at least some control and whose HTML > > structure I know. > > > Of course the JavaScript code should at the same time wait for > > window.onload as a last resort. > > > Not sure if this is possible in any decent quality at all, but > > I'd like to give it a try if I see a chance. > > Dean Edwards addressed the 'window.onload' problem in his [we]blog:http://dean.edwards.name/weblog/2005/09/busted/http://dean.edwards.name/weblog/2006/06/again/ For God's sake, don't listen to him. :( > > But his 'solution' is still incomplete - it covers only IE, Safari and > Firefox (versions available in 2006). It was bullshit then and it is bullshit now. It is known to cause Operation Aborted errors. IIRC, jQuery figured this out recently (three years later). Search their archive. > > Yahoo has the 'onDOMReady' method:http://developer.yahoo.com/yui/event/#ondomready I'm sure that's nonsense too. The fact is that there is no way to do it in IE. You can use a timeout at the very bottom of the document (just before the closing BODY tag). But that's no guarantee against the Operation Aborted show-stopper. The "frameworks" don't like that though as they seem to think their users are too stupid to use conditional comments, preferring a "cool" hack that "just works" (most of the time). ;) So design your documents/apps in accordance with this reality (i.e. don't use too many images, Flash movies, etc.) That's it.
From: JR on 28 Dec 2009 19:51 On Dec 28, 10:20 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > On Dec 28, 5:00 pm, JR <groups_j...(a)yahoo.com.br> wrote: > > > On Dec 28, 11:55 am, Hans-Georg Michna <hans- > > > georgNoEmailPle...(a)michna.com> wrote: > > > Hi everybody; hope you all got over Xmas in good shape. > > > > The following may be a frequently asked question, but I haven't > > > seen any inspiring answer. > > > I didn't find any entry about that in the c.l.js FAQ. > > There isn't one. > > > > > > > > Does anybody here have a good idea or some simple working code > > > to solve the problem of having JavaScript code work on the DOM > > > just after it is loaded? window.onload has the obvious problem > > > that it waits for inessential content like images and can > > > therefore be very late. > > > > Resig & Co. have a working method in jQuery, but it relies on > > > browser sniffing and several browser-specific ways. Obviously > > > this is not guaranteed to work in future browsers and may need > > > regular updates. > > > > I am particularly looking for a method that can be done only in > > > JavaScript, without having to have any dedicated HTML code > > > embedded in documents. > > > > It seems that there can be no perfection here, so a method that > > > works in 99% of all cases will have to be good enough. > > > > I'm thinking along the lines of checking the document body and > > > waiting until it is stable for a short time like a second. Not a > > > heavenly solution, but at least totally browser-independent. > > > > I have already tried to append a tiny child node inside the body > > > and then checking one of its rendering parameters, but the > > > method will probably have to be refined, for example by checking > > > that no new elements are added after it because the DOM is still > > > being built up. > > > > How about checking some parameter of the document body in > > > regular, relatively slow intervals, like the total number of > > > nodes or some such? Browsers that allow JavaScript to access the > > > DOM before it is completely built should yield a rising, then > > > stabilizing number. Or perhaps the identity of the last node > > > could be checked, assuming that the DOM is always built > > > sequentially from HTML code. I need to do this only for web > > > pages over which I have at least some control and whose HTML > > > structure I know. > > > > Of course the JavaScript code should at the same time wait for > > > window.onload as a last resort. > > > > Not sure if this is possible in any decent quality at all, but > > > I'd like to give it a try if I see a chance. > > > Dean Edwards addressed the 'window.onload' problem in his [we]blog:http://dean.edwards.name/weblog/2005/09/busted/http://dean.edwards.na... > > For God's sake, don't listen to him. :( > > > > > But his 'solution' is still incomplete - it covers only IE, Safari and > > Firefox (versions available in 2006). > > It was bullshit then and it is bullshit now. It is known to cause > Operation Aborted errors. IIRC, jQuery figured this out recently > (three years later). Search their archive. Well, Dean Edwards' attempt was more like an incomplete search for a solution. I think he has given it up, since it's an 2006 entry in his blog. > > Yahoo has the 'onDOMReady' method:http://developer.yahoo.com/yui/event/#ondomready > > I'm sure that's nonsense too. The fact is that there is no way to do > it in IE. You can use a timeout at the very bottom of the document > (just before the closing BODY tag). But that's no guarantee against > the Operation Aborted show-stopper. The "frameworks" don't like that > though as they seem to think their users are too stupid to use > conditional comments, preferring a "cool" hack that "just works" (most > of the time). ;) > > So design your documents/apps in accordance with this reality (i.e. > don't use too many images, Flash movies, etc.) That's it. Thanks for that hint! Cheers, JR
From: Garrett Smith on 28 Dec 2009 19:58
Hans-Georg Michna wrote: > Hi everybody; hope you all got over Xmas in good shape. > I finished in good shape. > The following may be a frequently asked question, but I haven't > seen any inspiring answer. > > Does anybody here have a good idea or some simple working code > to solve the problem of having JavaScript code work on the DOM > just after it is loaded? What is the problem you want to solve that makes this seem an attractive solution? -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |