@Yes, you can do it but it is much neater to have all the linked javascript in the head of the document.
Please see the attached page loading chart (moodle.org startpage) showing how JS files in the header influence page load. 2 seconds between sec. 1.5 when JS #6 starts loading until sec 3.5 when JS #12 finishes loading the browser merely catches one single JS file after the other. For the user 2 valuable seconds long nothing visible happens. And parallel loading begins again after the last JS file is ready.
As Tim will handle JS most JS is loaded from the footer. Then the page and most visual elements are loaded and the page looks complete/nearly complete.
One JS file invoked from the header with JS that is needed while the page loads doesn't influence loading too much. It may be loading parallel to the CSS files as now.
And when CSS will be optimized and minified another advantage will be that while one or two CSS files load the browser can start fetching images. Page load will look much faster for the user.
When we estimate with the loading times shown here you can figure that the user get's the impression that the page is loaded about 2 seconds earlier. On the moodle.com start page for users visible page load will take roughly half the time.
@François and Mark - good points.
Topic 5 is important - "register.php" looks like a solution.
@Tim - the declarative approach demands more thinking beforehand. Afterwards Moodle doesn't need to search around hunting for files to include as it does now.
For example actually collecting module specific CSS is a search through all module directories on demand - again and again.
Other systems use the register approach and it's easy to work with. And Moodle is going to use events more in coming releases. Registering what you want or need will become self-evident in an event driven environment.
Because I work a lot with behavioural add-ons based on JavaScript in Moodle here my proposals:
Moodle JavaScript handling needs to be flexible enough to handle YUI and other JS frameworks if needed. YUI is too complex for easy implementations - most the time I work with jQuery. Especially because jQuery and YUI play together nicely.
From my point of view "modular" in Moodle's name needs to stand for a modular codebase too.
Following the YAHOO optimization rules Moodle JavaScript handling needs to be able to load JS from the footer. My survey about theme and JavaScript handling speed have proven that pages load significantly better when behavioural add-ons (as JavaScript code) are loaded after page content.
Seldom special functions need to load before the page loads. For example code that checks for onAvailable for DOM elements. Moodle needs to be able to load this JS before the page from header. All JS using "on DOM ready" can load from the footer. Therefore I load most JS from the footer in my themes.
In this context it's also good to know that browsers load and process JS files one after the other.
To keep the number of files sent to the browser small following the YAHOO speed rules Moodle should handle JS similar to the CSS in themes. Create granulated JS and collect it into one file when the page is build.
Create JS as in Tim' proposal 3 and deliver as in proposal 1.
To be able to include only the needed JS other systems use a JS stack - adding information about preload (from header) or normal load (from footer, default). Every part using JS adds their JS to the stack and Moodle builds two big JS files delivered to the browser - a small one loaded from header and the bigger one loaded from footer.
As Tim mentioned some parts of Moodle may handle JS individually if needed.
Many times JS code can be executed after the page has loaded. Code which needs to be executed immediately better uses individual optimized JavaScript than relying on huge and definitely slower JS frameworks like YUI (see topic 7).
Replace the huge overlib.js with YUI functionality. It is only used for the calendar when I am right.
Load the media script UFO only when needed.
Write central core JS in optimized JavaScript which works faster without YUI overhead. Replace all the other functions with YUI.
In my implementations I use optimized JS for core functionality (loaded from the footer). Afterwards jQuery is loaded form the footer preparing the pages for the behavioural add-ons. My speed researches proved that this way with separate optimized code plus standard framework code you get the best compromise concerning performance on one hand and ease of implementation on the other.
The YAHOO rules very clearly describe the difference between first time page load and cached page load. They also describe the importance of the first time page impression.
For a good first time page impression the amount of data sent to the browser needs to be as small as possible. Think about Moodle first contact sessions in training situations. These first time impressions are crucial for system acceptance.
Therefore it is important to send only the needed JS to the browser and not all code on every page.
Create documentation for the Moodle core JS. Then developers don't tend to create the same functionality again and again as it happens now every once in a while.
To reach the round amount of ten topics: Moodle needs to integrate jQuery too