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?
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 <chsny...@gmail.com> wrote:
> 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?
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:
--- 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).
On Thu, May 8, 2008 at 7:10 PM, machineghost <machinegh...@gmail.com> 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 <chsny...@gmail.com> 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.
>> 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?
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.
On Thu, May 8, 2008 at 12:16 PM, Per Cederberg <cederb...@gmail.com> 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:
> 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 <machinegh...@gmail.com> 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 <chsny...@gmail.com> 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.
>>> 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?
On Thu, May 8, 2008 at 11:02 PM, David Janes <davidja...@blogmatrix.com> 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 <b...@redivi.com> 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 <cederb...@gmail.com> >> 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:
>> > 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 <machinegh...@gmail.com> >> > 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 <chsny...@gmail.com> 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.
>> >>> 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?
|
