Urs Hunkler

Yep, JS is collected and delivered by "javascripts.php". This is the file you may check for your JS code.

@extra javascripts

I got extra JS loaded the following way:
_ save your JS files in the "yourtheme/javascript/" folder
_ add the following setting to config.php
/** List of javascript files that need to be included on each page */ $THEME->javascripts = array( 'jquery-1.3.2.min', 'jquery.tools.min' );

Thanks Petr, the page load time is a lot faster now.

And I changed the parameter order to display the "sheet" name first in the styles_debug.php urls. In the moment the sheet name comes last and you need to check the end of the long url to find out the name of CSS file. Please consider to integrate this change into core.

The "Theme designer mode" has a major issue.

A course page loads in 2 sec in normal mode. The same page takes about 16.5 sec in "Theme designer mode". (styles about 9 sec., images about 6 sec.) This load time is not acceptable because it means waiting for each page reload. Normal page change times are essential when working on page design with CSS and/or XHTML.

One solution might be to build one styles.php in both modes. As is for normal cached mode and one where you don't copy the CSS into one file but collect all CSS with @import like "@import url("http://server.com/moodle_20/theme/standard/style/layout.css");" in one file and don't cache. (Themes not accessible by the web server can't be delivered this way. But in a development environment you can always save the theme in the themes folder.)

Collecting the CSS files with @import I implemented for "design mode" in Moodle 1.9 and it works well. Besides the much shorter load time another advantage of this approach is that you see all CSS files with their names in the browser and this helps a lot while developing CSS.

The existing approach is technical and not at all user friendly. Please change the "Theme designer mode".

The "collapsing navbar" is a very special beast. I think the functionality is marvelous - the actual implementation and look is awful.

Such a central navigation element needs to be implemented very close into the overall design and navigation. Now it looks to me like an alien element. And the "collapsing navbar" is quite different from the navigation patterns users know and expect.

It needs for example to be part of an horizontal menu like the one on moodle.org when one is present. A horizontal menu plus this side menu would break common navigation expectations and experiences.

As you see we need to be able to implement the "collapsing navbar" in different ways. Can the "collapsing navbar" be implemented with a renderer giving the opportunity to change the integration into the page with a different renderer when necessary?

Here again a flexible approach would make a good solution.