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: JR on 29 Dec 2009 06:55 On Dec 28, 10:51 pm, JR <groups_j...(a)yahoo.com.br> wrote: > 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! There is an excellent article in Peter Michaux's site about the window.onload problem - it also states that a robust technique for early page enlivenment is not possible across the big four browsers (IE, Safari, Mozilla and Opera). The link to that article goes below: http://peter.michaux.ca/articles/the-window-onload-problem-still But, in a later article, Peter has dropped the ball when he said that the problem was solved by - believe it or not - jQuery, which uses the "Dean Edwards' technique". I can see David Mark really furious... OMG. http://peter.michaux.ca/articles/the-window-onload-problem-really-solved All in all, I'll stick with David's advice. But I am waiting for his comments on myLibrary's documentReady. Cheers, JR
From: David Mark on 30 Dec 2009 01:23 On Dec 29, 6:55 am, JR <groups_j...(a)yahoo.com.br> wrote: > On Dec 28, 10:51 pm, JR <groups_j...(a)yahoo.com.br> wrote: > > > > > 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! > > There is an excellent article in Peter Michaux's site about the > window.onload problem - it also states that a robust technique for > early page enlivenment is not possible across the big four browsers > (IE, Safari, Mozilla and Opera). The link to that article goes below:http://peter.michaux.ca/articles/the-window-onload-problem-still > > But, in a later article, Peter has dropped the ball when he said that > the problem was solved by - believe it or not - jQuery, which uses the > "Dean Edwards' technique". I can see David Mark really furious... OMG.http://peter.michaux.ca/articles/the-window-onload-problem-really-solved That's an outdated article. > > All in all, I'll stick with David's advice. But I am waiting for his > comments on myLibrary's documentReady. I haven't looked at that "add-on" script in years. Not proud of it at all (and will likely clean it up a bit before the year's out). Basically, it is an extra (optional) script that you put at the very end of the document (before the closing BODY tag). A timeout is used for IE (using conditional compilation). I also see it has some extra baggage that can be removed. It also detects the readyState property and polls it when available. Pretty hack-y, but it's a rock compared to the Dean Edwards hack (or this new doScroll abomination). My recommendation is to avoid such things (mine or otherwise). http://www.cinsoft.net/mylib-doc0.html#core And one caveat. Though I have never had any problems with it and have tested a ton of browsers/configurations (not proof of anything, of course), Kangax reported that he had a problem with the test page with the new Konquerer (not sure if it was a release version or not). IIRC, the document ready listener was entered while document.body was null (as if the HEAD were still parsing). Either that or this function is failing (very) unexpectedly. getBodyElement = function(docNode) { docNode = docNode || global.document; if (isRealObjectProperty(docNode, 'body')) { return docNode.body; } if (typeof getEBTN == 'function') { return getEBTN('body', docNode)[0] || null; } return null; }; I can't imagine the problem has anything to do with a script at the _end_ of the BODY (more likely there was a problem with the DOMContentLoaded event). As I don't care to build Konquerer, I'll offer a free license to anyone who can reproduce the problem. If I made a mistake, I'll be the first to admit it (and will fix it without argument). :) http://www.cinsoft.net/mylib-builder.asp
From: JR on 30 Dec 2009 07:16 On Dec 30, 4:23 am, David Mark <dmark.cins...(a)gmail.com> wrote: > On Dec 29, 6:55 am, JR <groups_j...(a)yahoo.com.br> wrote: > > > > > On Dec 28, 10:51 pm, JR <groups_j...(a)yahoo.com.br> wrote: > > > > 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! > > > There is an excellent article in Peter Michaux's site about the > > window.onload problem - it also states that a robust technique for > > early page enlivenment is not possible across the big four browsers > > (IE, Safari, Mozilla and Opera). The link to that article goes below:http://peter.michaux.ca/articles/the-window-onload-problem-still > > > But, in a later article, Peter has dropped the ball when he said that > > the problem was solved by - believe it or not - jQuery, which uses the > > "Dean Edwards' technique". I can see David Mark really furious... OMG.http://peter.michaux.ca/articles/the-window-onload-problem-really-solved > > That's an outdated article. > > > > > All in all, I'll stick with David's advice. But I am waiting for his > > comments on myLibrary's documentReady. > > I haven't looked at that "add-on" script in years. Not proud of it at > all (and will likely clean it up a bit before the year's out). > > Basically, it is an extra (optional) script that you put at the very > end of the document (before the closing BODY tag). A timeout is used > for IE (using conditional compilation). I also see it has some extra > baggage that can be removed. > > It also detects the readyState property and polls it when available. > Pretty hack-y, but it's a rock compared to the Dean Edwards hack (or > this new doScroll abomination). > > My recommendation is to avoid such things (mine or otherwise). > > http://www.cinsoft.net/mylib-doc0.html#core > > And one caveat. Though I have never had any problems with it and > have tested a ton of browsers/configurations (not proof of anything, > of course), Kangax reported that he had a problem with the test page > with the new Konquerer (not sure if it was a release version or not). > IIRC, the document ready listener was entered while document.body was > null (as if the HEAD were still parsing). Either that or this > function is failing (very) unexpectedly. > > getBodyElement = function(docNode) { > docNode = docNode || global.document; > if (isRealObjectProperty(docNode, 'body')) { return > docNode.body; } > if (typeof getEBTN == 'function') { return getEBTN('body', > docNode)[0] || null; } > return null; > }; > > I can't imagine the problem has anything to do with a script at the > _end_ of the BODY (more likely there was a problem with the > DOMContentLoaded event). As I don't care to build Konquerer, I'll > offer a free license to anyone who can reproduce the problem. If I > made a mistake, I'll be the first to admit it (and will fix it without > argument). :) > > http://www.cinsoft.net/mylib-builder.asp Man, I was really hoping for a professional answer like that! Thanks a lot for clarifying my doubts. -- JR
From: Hans-Georg Michna on 31 Dec 2009 09:36 On Mon, 28 Dec 2009 16:58:50 -0800, Garrett Smith wrote: >Hans-Georg Michna wrote: >> Hi everybody; hope you all got over Xmas in good shape. >I finished in good shape. Ha! So now for switching years! >> 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? Putting a table of contents into a web page, particularly inside a Content Management System, that is clickable and chapters reachable from the outside. The many known TOC scripts don't do all of this. I'm now thinking about a relatively simple solution that will work well in many newer browsers and will still work in all others through window.onload. The basic idea is to put event handlers on both events if possible, then remove them from both as soon as one of them fires, while leaving any foreign handlers in place (except for window.onload, which we want to fire only once anyway). function waitForDom() { // Keep preexisting handler and append own handler: var precedingOLHandler = window.onload; // Try readyState if the browser has it: if (document.readyState) { function waitForDom.isDocumentReady() { return document.readyState === "interactive" || document.readyState === "complete"; } if (waitForDom.isDocumentReady()) { doTheActualWork(); return; } var precedingORSCHandler = document.onreadystatechange; document.onreadystatechange = function () { if (precedingORSCHandler) precedingORSCHandler(); if (waitForDom.isDocumentReady()) { // Reset handlers, remove own handlers: document.onreadystatechange = precedingORSCHandler; window.onload = precedingOLHandler; fillToc(); } } } // Use window.onload also, for all other browsers: window.onload = function () { if (precedingOLHandler) precedingOLHandler(); // Reset handlers, remove own handlers: if (document.readyState) document.onreadystatechange = precedingORSCHandler; window.onload = null; doTheActualWork(); } } Have not thoroughly tested this and may come up with improvements. Have thought a while about the closures on the old handlers, but the entire program should be garbage-collected anyway, after it is done. I'm not very experienced yet in these things. Anyway, this looks much cleaner than the Dean Edwards code, but will probably still work in many browsers, at least once Firefox 3.6 (with document.readyState) is gaining acceptance. It is interesting to notice how certain inventions like document.readyState or, for example, element.innerHTML gain universal acceptance without being formally standardized. The downside is that it is not enough to read the standard. Hans-Georg
From: Hans-Georg Michna on 31 Dec 2009 18:22
It didn't quite work. document.readyState === "interactive" happens already when the DOM barely exists and is by no means complete. Has anybody seen any specification of whether "complete" happens before window.onload? Or do they happen at roughly the same time? If the latter, then I could simply use window.onload only. Currently I use this: function waitForDomComplete() { // Keep preexisting handler and append own handler: var precedingOLHandler = window.onload; // Use readyState if the browser has it: if (document.readyState) { if (document.readyState === "complete") { doTheActualWork(); return; } var precedingORSCHandler = document.onreadystatechange; document.onreadystatechange = function () { if (precedingORSCHandler) precedingORSCHandler(); if (document.readyState === "complete") { // Reset handlers, remove own handlers: document.onreadystatechange = precedingORSCHandler; window.onload = precedingOLHandler; doTheActualWork(); } } } // Use window.onload also, for all other browsers: window.onload = function () { if (precedingOLHandler) precedingOLHandler(); // Reset handlers, remove own handlers: if (document.readyState) document.onreadystatechange = precedingORSCHandler; window.onload = null; doTheActualWork(); } } I think it is quite possible that I'm doing far too much, and a simpler piece of code would have nearly or entirely the same effect. Hans-Georg |