Yes, I think the suggestion was to port from jQuery with consideration of at least one other working implementation.
/Per On Thu, May 8, 2008 at 11:02 PM, David Janes <[EMAIL PROTECTED]> wrote: > And just to jump in here -- surely there's a "done" solution for this that > we like, can we not just port something from another toolkit? > Regards, etc... > > On Thu, May 8, 2008 at 4:34 PM, Bob Ippolito <[EMAIL PROTECTED]> wrote: >> >> Yeah, the major problem of doing a synthetic ondomload event like that >> is that you need to instrument all of your pages with that script tag >> at the bottom. It's "nicer" to do it via DOM calls because you don't >> need to change the markup. >> >> -bob >> >> On Thu, May 8, 2008 at 12:16 PM, Per Cederberg <[EMAIL PROTECTED]> >> wrote: >> > >> > Antti Koivisto, one of the Safari browser developers, wrote an >> > interesting blog entry about page loading recently. It explains some >> > of the difficulties involved from a browser perspective: >> > >> > http://webkit.org/blog/166/optimizing-page-loading-in-web-browser/ >> > >> > And a small extract of the most relevant section: >> > >> > --- >> > Problems start when a document contains references to external >> > scripts. Any script can call document.write(). Parsing can't proceed >> > before the script is fully loaded and executed and any >> > document.write() output has been inserted into the document text. >> > Since parsing is not proceeding while the script is being loaded no >> > further requests for other resources are made either. This quickly >> > leads to a situation where the script is the only resource loading and >> > connection parallelism does not get exploited at all. A series of >> > script tags essentially loads serially, hugely amplifying the effect >> > of latency. >> > --- >> > >> > So, in my understanding, putting a <script> tag at the very end of the >> > HTML text on the page should be nearly identical to actually waiting >> > for the onDOMLoad event. All the document text should have been parsed >> > already and be available in the DOM tree. >> > >> > One of the many issues with "onload" is also the latency involved in >> > loading images and CSS files, which actually adds up to quite some >> > time (as most browsers only request 2 objects simultanously per web >> > site). >> > >> > /Per >> > >> > On Thu, May 8, 2008 at 7:10 PM, machineghost <[EMAIL PROTECTED]> >> > wrote: >> >> >> >> As I understand things (and I am by no means a JS event sequence >> >> expert), the ordering is as follows: >> >> >> >> 1. Browser reads page line by line; every time it reads enough lines >> >> to complete a JS statement, it executes that statement; meanwhile, non- >> >> JS content is loaded in to the DOM as it is read >> >> 2. Once the browser has finished reading the page it will have a >> >> complete DOM ... in memory. >> >> 3. The browser will then render that DOM tree to your screen. >> >> 4. Once it has finished rendering the DOM tree, it invokes any >> >> "onload" events. >> >> >> >> Technically that's wrong, because the first three things are really >> >> happening simultaneously (ie. the browser starts rendering the top of >> >> the page even before it has a complete DOM loaded), but it's simpler >> >> to think of it that way (because they will almost always finish in >> >> that order). >> >> >> >> The "problem" with your code, as I understand it, is that your code >> >> goes off in #1, which means there is no guarantee that a complete DOM >> >> will exist. If you instead wait for "onLoad" though, you have to wait >> >> for the page to render. So what people who are interested in the >> >> "onDOMLoad" event are after is getting an event that triggers after 2 >> >> but before 3. That way, you don't have to wait for the page to >> >> render, and as long as your code doesn't require any rendered >> >> information (like "what are the dimensions of $('someElement')") it >> >> should work fine. >> >> >> >> But all of the above was written with my very flawed understanding of >> >> the JS event model; please take it with a giant helping of salt. >> >> >> >> Jeremy >> >> >> >> On May 8, 9:37 am, csnyder <[EMAIL PROTECTED]> wrote: >> >>> Hi MochiKitters, >> >>> >> >>> I've been using the following trick successfully for a few months now. >> >>> It _seems_ to work fine cross-browser and cross platform. >> >>> >> >>> <script type="text/javascript"> >> >>> signal(window,'ondomload'); >> >>> </script> >> >>> </body> >> >>> </html> >> >>> >> >>> But based on the recent thread about implementing ondomload, I assume >> >>> that there must be cases when a simple signal at the end of the dom >> >>> isn't enough. >> >>> >> >>> Can anyone give me a quick earful about why the above isn't the best >> >>> way to do it? >> >>> >> >>> -- >> >>> Chris Snyderhttp://chxo.com/ >> >> > >> >> >> > >> > > >> > >> >> >> > > > > -- > David Janes > Founder, BlogMatrix > http://www.blogmatrix.com > http://www.onaswarm.com > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~----------~----~----~----~------~----~------~--~---
