Morten Nielsen

Morten,

> NO! Scripts are not allowed in the header.

Yes they are.

http://www.w3.org/TR/html401/sgml/dtd.html#head.content
http://www.w3.org/TR/html401/sgml/dtd.html#head.misc
That shows the list of elements that can go into the HEAD, according to the
HTML 4.01 DTD. The first element mentioned in %head.misc; is SCRIPT.

> Read the HTML spec.

"This element may appear any number of times in the HEAD or BODY of an HTML
document."

> try and validate a page that has scripts in the header.

I do this all the time, and it works beautifully. If yours is not
validating, it is for a different reason, and is not related to the SCRIPT
element being inside the HEAD. The validator's output is not always very
clear though, so it's understandable that some of its messages may be
confusing in that respect.

Scripted event attributes do not work on the HEAD element though, while they
do work on the BODY. But that has nothing to do with where most scripts
(using SCRIPT elements) should go.


Mark 'Tarquin' Wilton-Jones - author of http://www.howtocreate.co.uk/

Morten,

> Sorry I meant to say XHTML.

XHTML and HTML use the same rules for what elements and attributes can go in
what elements. The element names must be lower case, but other than that,
both allow it in the HEAD.

> But no matter what, they are bad practice
> because they block the loading of the page.

Either way, they will always have to be loaded, and the page loading will
still stall at some point. Generally, browsers will buffer what they had of
the previous page until they have something to display - typically after
scripts in the HEAD. This makes the response often feel faster if they are
in the HEAD, since it will display the page very rapidly after loading,
where a script later down the page can trigger more progressive renders.
This is of course academic, and down to user tastes.

The reasons for keeping scripts in the HEAD are to separate the scripts from
the content. It makes them easier to find when editing, and keeps the
clutter out of your document. It is good practice to put it in the HEAD, not
the BODY where possible.

They will also be loaded before they are used, that's a guarantee, and the
user will not be able to interact with the document until the scripts have
prepared it, if the script is written correctly. That's actually quite
important in many cases, since the user could click on something that has an
onclick handler or JavaScript URL, and if the scripts have not been loaded
yet, they will get an error. This is actually one of the things that the
HEAD section is designed for - to load the related content that is not
displayed on its own as content. This is also why the specs demand that CSS
rules go in the HEAD, and not anywhere else.

> I never said it didn't work. But there are a lot of things that are wrong
> that browsers are pretty laxed about.

There is nothing wrong. It validates as both HTML and XHTML, and is
semantically correct. It is even using the HEAD for what it was designed
for.


Tarquin

Morten,

> The problem caused by scripts is that they block parallel downloads.

That will still happen no matter where the script appears in the document.
Images are still going to be being downloaded when the script element is
parsed later in a document. Some browsers are still capable of doing
parallel downloads of subsequent content even with scripts being downloaded.
IE 8 and Safari are prime examples.

> I don't get why you make it sound like progressive rendering is slower.

It can feel slower to a user in many (but not all) cases. Safari's perceived
speed is based on that. Progressive rendering only feels faster when you get
a server that responds slowly (or has restricted bandwidth), so the loading
takes a very long time, where offscreen buffering causes a seeming failure
to load for that length of time. Browsers that have progressive rendering
often employ a compromise - initially using offscreen buffering, then
switching to progressive rendering if it takes too long.

[Ed. Each progressive render also causes a reflow, so does take real time
as well as the user seeing an incomplete page first, and begin waiting for
the completed one]

> I've never ever had to have javascript in the header to allow for
> executing script.

Sure, I said good practice, not the only way. Both ways work.

> you should wait until the page has fully loaded before hooking up your
> events.

This suggestion is good, but completely out of touch with the vast, vast
majority of Web pages. Authors simply do not want to do that (in some cases
because it can mean waiting for a long time for loading to complete, which
hurts progressive rendering, but often because they just don't like it), and
most use inline event handler attributes, as shown in all research I have
seen on the subject. But even if they do what you suggest, I would still
tell them that they should normally load the script in the HEAD, not at the
end of the BODY, or anywhere else.

The only reason I would suggest putting them at the end of the BODY is when
you need to make up for the lack of support for the non-standard
DOMContentLoaded event in various browsers. It could appear wherever needed
if using old-style document.write scripts, which are still used for a huge
number of scripts, especially ads.

So either way, I still stand by what I said in the tutorial. It is valid in
HTML and XHTML. It is semantically correct. It uses the elements for the
right purposes. It keeps the clutter out of the document and separates the
document content from the scripts. It makes them easier to maintain. It
avoids load timing problems when using inline event attributes and
JavaScript URLs. You have not given anything that outweighs those benefits,
and your original point was completely wrong - saying that it was not valid.

So thanks for bringing what you thought was an error to my attention. But
no, there is no such error in my tutorial, and I do not plan to change it
regarding this point.


Tarquin