When you load the script, has nothing to do with the dom. The script can
modify/alter the dom but the loading sequence is a completely new story. If
you use the jQuery ready() method, your script will be processed right after
the dom is loaded and before the images are loaded, which is what you want
if you want to alter the dom, but don't care about images being shown when
you do it.
The scripts you want to put in after the body is script that are not run
before the user interacts. That does not include behaviors, because you want
them to work as soon the user e.g. clicks an element (and he/she can do that
as soon as the page render).
IMHO you're better of gzipping your files (and of course minimize them) and
don't put more library (i.e. scripts) than you need.

On 7/17/07, Michael Geary <[EMAIL PROTECTED]> wrote:


> > > My understanding is we put script tags in the head so as to not
> > > clutter up the body DOM. I don't think it has anything to do with
> > > ready(), and I'm pretty sure ready() doesn't require
> > > script tags to be in the head...

> > Yes, but if you put the scripts at the end of the body you don't need
> > to use ready(), e.g. that is literally the same as using ready()...

> So why don't we just always put script tags at the end of the body?
> What's the disadvantage of that?

One disadvantage is that it can lead to sloppy display behavior when the
page loads.

The browser will never start rendering a page while the HEAD is loading.
But
once it starts loading the BODY, the browser is free to render a partial
page any time it feels like it. In practice, this doesn't usually happen
unless something causes the page loading to stall. In particular, if there
is a script tag that loads an external script, the browser is very likely
to
render the page using whatever it has available at that point.

You can see this in action on any typical newspaper site such as
www.mercurynews.com. Any time you navigate to a new page, stuff jumps
around
all over the place while the page loads. This is caused by the script tags
that are sprinkled willy-nilly throughout the page.

A script tag at the very end of the body is less likely to trigger this
behavior, but it could still happen if the script modifies DOM elements
earlier in the page. The browser reaches the script tag, and while it
waits
for the external script to load it decides to render what it has so far.
Then the script loads and modifies the page, so things jump around when
this
happens.

-Mike


Reply via email to