Hello theme designers, developers and also admins!
When working on new resource modules I discovered several problems in previous and later also current theme design. I tried to find some easy solutions, but in the end started thinking about the whole design of our themes. I came to conclusion that the current level of backwards compatibility in themes is limiting our progress in Moodle 2.0dev.
I have created a new proposal which outlines one potential way how to improve the themes framework. You can find it at http://docs.moodle.org/en/Development:Theme_changes_proposal
I believe this design further improves the flexibility of our API, gives even more power to theme designers and would simplify installation, customisation and upgrade of themes for ordinary admins. Technically there should not be any problems with the implementation, I already made a prototype that sort of works - it seems to work fine and solves the problems I wanted to fix originally.
Please read the proposal and let me know what you think either here or in the wiki comments page, thanks in advance.
Petr
Thank You for this revolutionary plan, Petr!
It will open many of those "closed doors" we have had before - I particularly like the new option to customize settings with settings.php (can we use it already? - I made some experiments with filtersettings.php before and if the procedure to change settings of themes directly from administration menu works the same way as changing the settings of filters it is a super cool feature for most administrators. To be able to modify themes without touching the actual files but by changing basic settings from theme administration menu.)
Most old sites may need to upgrade their themes but let's see it as challenge - to make upgrading of old themes simpler people need good documentation and examples about different ways to use new features. It would be nice if Moodle Masters and Theme Busters like You and Tim could add more of these excellent examples to documentation and if possible even some links to experimental demo themes (for moodle 2.0) for others who have not used for example yui grids before.
Still feeling a little bit wide-eyed with surprise (in a positive way!)... but always ready to learn new things...
Great!
Hi Petr,
that's a long read
To most aspects I can agree. Especially the opportunity for better caching is a huge advantage and long demanded.
1.) The aspect to remove the easy use of IE conditionals needs to be discussed in detail:
"Browser hacks
Old meta.php was used mostly for conditional loading of IE specific hacks. Open university developed alternative solution which adds browser specific classes to body html element."
In specific CSS loaded only in IE browsers you can add IE only CSS which breaks CSS validation. The main CSS which is validated in the page does not break this way. If the IE specific CSS must be integrated into the main CSS file, the CSS will not validate any more.
I use several IE specific CSS to make pages a bit more looking alike in IE. And I am glad that they don't break validation in the actual setup. You surely will find a way to let us use IE conditionals in 2.0.
Many CSS gurus recommend IE conditionals as a clean way to handle IE specific CSS without breaking validation.
One way out may be a sophisticated system to integrate browser specific CSS in a second file loaded conditionally - not only for IE.
2.) The use of YUI CSS foundation is ok - except YUI CSS Grids
"YUI CSS foundation
Why should we base our themes on YUI CSS foundation? Why not? The benefits are:
_ eliminates some different HTML defaults (margins, paddings, font sizes, etc.) (YUI CSS Reset)
_ consistent font sizing and better font-family degradation (YUI CSS Fonts)
_ incredibly simple table-less page layouts that include nesting (YUI CSS Grids)
_ the standard YUI CSS is already built on top of this foundation
Moodle will hugely benefit from using YUI CSS Reset and YUI CSS Fonts. All the inconsistent and many different font sizes used in Moodle now may be optimized. Great
I am massively against forcing all themes to use YUI CSS Grids and the very abstract and reduced XHTML syntax they use. Integrating YUI CSS Grids as an option is ok.
Why am I against YUI CSS Grids as a must?
All CSS Grid systems use fixed rules. Short and not always semantically correct id and class names and complex naming conventions make them difficult to learn and understand. They need to cover many page layouts - the rules get more important than easy to understand and to handle pages and semantic naming of the XHTML structure. The flexibility we get with the new page rendering in Moodle 2.0 will be much reduced when the YUI CSS Grid system must be used for the page layout.
I am so glad that Moodle 2.0 will offer for example the flexibility to create page layouts in an economic justifiable amount of time that integrate Moodle and Wordpress/Drupal/others visually - based on a common set of XHTML and CSS for both programs. When Moodle demands the YUI CSS Grid this door is closed again. All page design must follow the restricted Moodle rules - as now.
Many web designers like me work with their own CSS Grid system or use other systems. I am so glad that we can better use the know-how we have for Moodle 2.0 design. When Moodle demands the YUI CSS Grid system we will be forced to continue working Moodle specific and learn extra rules and APIs.
All the energy I had put into the discussions about Moodle templates/themes had the goal to make Moodle more flexible. From what I have seen so far in Moodle 2.0 I think Tim has done a great job and we will have a wonderful base for tremendous possibilities for great Moodle page designs. We can start to design and can stop to create "wallpapers" as we are forced with the current restricted possibilities. When you will force us to use the YUI CSS Grids much of the flexibility will be gone.
I decided not to work with any of the several CSS grids. They reduce my flexibility and creativity. I learn from them but I don't use them. They are too restrictive.
You write
"Core and custom themes could use the extremely simple and powerful YUI CSS Grids framework for page layout. I do not think we could quickly develop anything as reliable and compatible before the release of 2.0."
When Moodle developers want to use the YUI CSS Grid for Moodle pages it's ok - but only when the YUI CSS Grid is optional.
Please don't replace the old chains with new ones!
1) the IE conditionals are problematic because we can not load them in correct order if we use one huge CSS file - we need to apply them right after each theme. Somebody already implemented the body browser classes and it is used in some several places. OU proved it works fine for them too. I personally hate those CSS hacks that exploit inconsistencies of CSS handling in each browser.
I was very surprised to see some very ugly IE hacks with dark magic in RTL sheet
In short: I did not find any way to use IE conditionals together with one huge CSS - main problem in cascading into parent themes.
2) I agree we can not force YUI Grids on everybody - fortunately they or anything else are used only in layout files - they do not need to be mentioned directly in any theme.
In short: I like YUI Grids (because I am lazy), but it has to be 100% optional and very easy to replace.
I was very surprised to see some very ugly IE hacks with dark magic in RTL sheet
In short: I did not find any way to use IE conditionals together with one huge CSS - main problem in cascading into parent themes.
2) I agree we can not force YUI Grids on everybody - fortunately they or anything else are used only in layout files - they do not need to be mentioned directly in any theme.
In short: I like YUI Grids (because I am lazy), but it has to be 100% optional and very easy to replace.
Have you guys had a look at the boilerplate CSS framework? it's a " stripped down framework which provides the bare essentials to begin any project." It includes all of the resets and typographical niceties without any of the non-semantic naming conventions. Might be worth a look.
Does that play well with standard YUI widgets? We have started using YUI elements more in 2.0dev, anything that is not compatible with that in long term is going to bring us problems.
I personally do not care much which JS&CSS framework we use (because I am just starting to use them in my new code), but I prefer one consistent solution that is able to service majority of our needs. And this solution has to be actively maintained and supported by its authors.
Some two years ago it was decided we are going to use YUI for our new ajaxy stuff - I do not think we thought about CSS much at that time (I was not involved in that myself). Incidentally we started using YUI framework more and more in the new code. Gradually we started hitting more and more JS and CSS problems. Tim's great theme refactoring seems to solve all known JS problems. However the CSS issues were not addressed and that is what I am trying to solve now in my proposal.
We could go back and choose different JS and CSS framework, but it would mean to throw away a lot of code and knowledge we gained in the last two years while learning how to use the YUI framework.
I do like the style reset and font standardisation they have in YUI, so my +1 to use it in all our CSS, the main reason is our YUI widgets in standard code will not work without that.
Grids is a different beast - it is independent from the rest of YUI CSS and it is possible to use something completely different in layout scripts - this is in fact the whole point of layouts in themes.
Petr
I personally do not care much which JS&CSS framework we use (because I am just starting to use them in my new code), but I prefer one consistent solution that is able to service majority of our needs. And this solution has to be actively maintained and supported by its authors.
Some two years ago it was decided we are going to use YUI for our new ajaxy stuff - I do not think we thought about CSS much at that time (I was not involved in that myself). Incidentally we started using YUI framework more and more in the new code. Gradually we started hitting more and more JS and CSS problems. Tim's great theme refactoring seems to solve all known JS problems. However the CSS issues were not addressed and that is what I am trying to solve now in my proposal.
We could go back and choose different JS and CSS framework, but it would mean to throw away a lot of code and knowledge we gained in the last two years while learning how to use the YUI framework.
I do like the style reset and font standardisation they have in YUI, so my +1 to use it in all our CSS, the main reason is our YUI widgets in standard code will not work without that.
Grids is a different beast - it is independent from the rest of YUI CSS and it is possible to use something completely different in layout scripts - this is in fact the whole point of layouts in themes.
Petr
That sounds perfectly reasonable to me - use the YUI reset and YUI font standards but develop a separate, more semantic, layout system that specifically suits our needs. I have no particular desire to move to Boilerplate except it's very lean and doesn't force specific classes upon the designer for specifying layouts. If we can get this same benefit from the YUI CSS, that's great.
I also would vote for "a separate, more semantic, layout system that specifically suits our needs". I'm a bit afraid of becoming too dependent on YUI.
JFTR I would also like to point to another discussion on maintainable CSS (http://moodle.org/mod/forum/discuss.php?d=126009 ).
"CSS Systems for writing maintainable CSS"
by Natalie Downe
http://natbat.net/2008/Sep/28/css-systems/
advocates a pragmatic approach to CSS design and doesn't speak too well of frameworks:
"In my opinion, CSS frameworks decrease the maintainability of code.
Simply introducing this extra abstraction now means that to maintain the site you have to know
not only CSS but also the framework that was used - down to the specific version."
Cheers,
Frank
JFTR I would also like to point to another discussion on maintainable CSS (http://moodle.org/mod/forum/discuss.php?d=126009 ).
"CSS Systems for writing maintainable CSS"
by Natalie Downe
http://natbat.net/2008/Sep/28/css-systems/
advocates a pragmatic approach to CSS design and doesn't speak too well of frameworks:
"In my opinion, CSS frameworks decrease the maintainability of code.
Simply introducing this extra abstraction now means that to maintain the site you have to know
not only CSS but also the framework that was used - down to the specific version."
Cheers,
Frank
I am afraid it is a bit too late, we already depend on YUI framework in many places - it would take months to start using something else. You should have voiced your concerns two years ago, sorry.
This proposal is not a place to discuss removal of YUI, instead I am trying to make it easier to use both for developers and theme designers.
I never really cared which framework, but it has to be just one - I am not going to learn 3 other frameworks and develop tons of our custom hacks supplementing them. I suppose all other core developers share my view.
If you are concerned about performance there are very many other sloppy code areas that may be significantly improved, the JS framework performance is not our major limiting factor imho.
Petr
This proposal is not a place to discuss removal of YUI, instead I am trying to make it easier to use both for developers and theme designers.
I never really cared which framework, but it has to be just one - I am not going to learn 3 other frameworks and develop tons of our custom hacks supplementing them. I suppose all other core developers share my view.
If you are concerned about performance there are very many other sloppy code areas that may be significantly improved, the JS framework performance is not our major limiting factor imho.
Petr
If only I had known Moodle two years ago 
My concerns are not about YUI in general but about using YUI as a CSS framework.
Frank
My concerns are not about YUI in general but about using YUI as a CSS framework.
Frank
But Frank,
you don't have to use yui as CSS framework... 
You can as well create a custom theme and use any code you want in layout.php, layout-home.php and other layout files.
Petr is planning to use yui grids and related css in standard theme but you don't have to use standard theme in moodle 2.0.
I tested today http://960.gs/ ( 960 Grid System ) that some people seem to call the best grid system, YAML http://www.yaml.de/en/ and http://builder.yaml.de/ and TSG CSS Framework but they don't seem to have big differences to YUI Grids - they all look more complex than normal css for 3 divs...
http://www.tripwiremagazine.com/tools/design/45-css-grid-systems-layout-generators-and-tutorials-that-every-designer-should-know.html has some more examples about grid systems.
Let's try that YUI based css and if it does not work we can always come back to old <table id="layout-table" summary="layout">...
And when the prototype of new standard theme is ready for testing and when the dust has settled people may start thinking about non-3-column and non-typical-moodle layouts and design of moodle 2.0 themes.
I don't want to bury grids before we have seen how they work - the main difference I noticed was in size of all fonts and settings. Demo grids were like editor plugins with smallest possible font size compared to current standard theme... 
Thanks! I am going to finish my proposal tomorrow (renders and templates) and ask MD and Tim for their opinions too.
There's a lot to go through. Please don't mind my list of thoughts.
1.) Disabling old themes from selection in 2.0 is a great idea. I'm all for breaking old themes if it brings greater flexibility and speed to the software. With that said, succinct documentation needs to be provided to help people upgrade their old themes.
2.) I'm not sure I understand the discussion about YUI CSS being optional. Will Standard use this CSS framework? Would all themes using Standard as a parent not also then use the framework? If Standard uses the CSS framework, would a new theme that uses Standard as a parent need its own set of layout templates to remove the YUI CSS grid classes?
I guess I just need a little more information on how the YUI CSS framework would be optional.
I'd also like to hear Petr's and Urs's feedback on using the lighter, more semantic Boilerplate CSS framework instead.
3.) I plan to develop multiple themes with different color variants. Settings.php gets my big +1.
4.) Can you explain the difference between the "layout templates" in layout/ and the "templates" that will go into template/
5.) Theme caching - great. Theme designer mode - also great.
6.) Meta.php - I have to agree with Urs: I'd rather break validation in an IE specific stylesheet. My +1 to keep this in one form or another.
If we were to go with a browser-specific body class, that's great. I'd probably still place all IE specific styles in an IE-specific stylesheet and call to them manually in the theme's template files.
7.) Themes in dataroot - I think this would be fine as an option in settings.php. Furthermore, I think it would be great if the CSS files could be accessed and edited directly through the Moodle interface (much like the language files are now). Any changes to the CSS through the web interface will be saved to the dataroot. The admin for the site can set permissions for who gets to see and edit these sheets which can be stored in dataroot at the course level also.
8.) Few themes in the official distribution: I've been asked to create 20 new themes to be shipped with 2.0. I can certainly see the appeal of cutting this down to, say, 3 themes as you've suggested, as long as their is a web interface to preview and download themes inside Moodle.
However, the database providing the themes seen through this interface should not be the one located at http://moodle.org/mod/data/view.php?id=6552. A separate database containing only regularly updated, officially supported themes should be used instead.
1.) Disabling old themes from selection in 2.0 is a great idea. I'm all for breaking old themes if it brings greater flexibility and speed to the software. With that said, succinct documentation needs to be provided to help people upgrade their old themes.
2.) I'm not sure I understand the discussion about YUI CSS being optional. Will Standard use this CSS framework? Would all themes using Standard as a parent not also then use the framework? If Standard uses the CSS framework, would a new theme that uses Standard as a parent need its own set of layout templates to remove the YUI CSS grid classes?
I guess I just need a little more information on how the YUI CSS framework would be optional.
I'd also like to hear Petr's and Urs's feedback on using the lighter, more semantic Boilerplate CSS framework instead.
3.) I plan to develop multiple themes with different color variants. Settings.php gets my big +1.
4.) Can you explain the difference between the "layout templates" in layout/ and the "templates" that will go into template/
5.) Theme caching - great. Theme designer mode - also great.
6.) Meta.php - I have to agree with Urs: I'd rather break validation in an IE specific stylesheet. My +1 to keep this in one form or another.
If we were to go with a browser-specific body class, that's great. I'd probably still place all IE specific styles in an IE-specific stylesheet and call to them manually in the theme's template files.
7.) Themes in dataroot - I think this would be fine as an option in settings.php. Furthermore, I think it would be great if the CSS files could be accessed and edited directly through the Moodle interface (much like the language files are now). Any changes to the CSS through the web interface will be saved to the dataroot. The admin for the site can set permissions for who gets to see and edit these sheets which can be stored in dataroot at the course level also.
8.) Few themes in the official distribution: I've been asked to create 20 new themes to be shipped with 2.0. I can certainly see the appeal of cutting this down to, say, 3 themes as you've suggested, as long as their is a web interface to preview and download themes inside Moodle.
However, the database providing the themes seen through this interface should not be the one located at http://moodle.org/mod/data/view.php?id=6552. A separate database containing only regularly updated, officially supported themes should be used instead.
1.) Disabling old themes from selection in 2.0 is a great idea - yay! this was my biggest worry
2.) I'm not sure I understand the discussion about YUI CSS being optional - see my previous post, to sum it up, YUI is comprised of - loaded in following order:
* style reset - must be loaded before any other CSS, levels the playing field for all browsers, it should not interfere much with any standard compliant CSS; without this other YUI CSS looks different in each browser; this should help us write nicer CSS with fewer hacks too
* font sizing - platform and browser dependent and accessible font sizing - looks like a good idea
* CSS for each YUI widget - does not interfere with any other CSS
* YUI CSS Grids - does not interfere with other CSS, it is used only if you specify class attribute
4.) Can you explain the difference between the "layout templates" in layout/ and the "templates" that will go into template/?
* layout - the whole page layout - divides page into areas like header, navigation, blocks, footer, main content - mostly html layout, some PHP logic - here we need the column layouts, here we could use YUI Grids or anything else - it is just the choice of Theme designer
* renderer - programatic construction of HTML code - such as printing of headers or tabs - a lot of PHP logic is included
* template - kind of bigger html fragment, something like visualisation of forum post, may include some PHP, simple types may contain only html markup and some variables
This is not explained much in my proposal, because I am still working on this part - discussing it with David, studying Tim's proposal, trying to come with some new solutions.
6.) Meta.php
Browser specific body class was the only technical solution I found that allows us to put themes into dataroot or any other place that is not accessible via web. And yes, you may still use a separate file for these hacks - the difference is you need to include the .ie7/.ie6 modifiers
7.) Themes in dataroot - ... edited directly through the Moodle interface...>
My -1, editing of any CSS or file in downloaded theme create big upgrade and maintenance problems - exactly the kind of problems we have now - I think using more theme settings is better solution for administrators. Please note that the recommended step for each major upgrade is to copy just main config.php and then download fresh versions of everything including the themes - if you have modified something you usually loose tweaks or may have conflicts if cvs used.
8.) Few themes in the official distribution: I've been asked to create 20 new themes to be shipped with 2.0. I can certainly see the appeal of cutting this down to, say, 3 themes as you've suggested, as long as their is a web interface to preview and download themes inside Moodle.
However, the database providing the themes seen through this interface should not be the one located at http://moodle.org/mod/data/view.php?id=6552. A separate database containing only regularly updated, officially supported themes should be used instead.
Installing and updating of themes is very problematic now, that is probably the reason why Martin wanted so many of them - and I agree we do need many of them, the question is where to have them. And yes, I agree we have to do something with our contrib - more quality review, ratings, recommendations, etc.
2.) I'm not sure I understand the discussion about YUI CSS being optional - see my previous post, to sum it up, YUI is comprised of - loaded in following order:
* style reset - must be loaded before any other CSS, levels the playing field for all browsers, it should not interfere much with any standard compliant CSS; without this other YUI CSS looks different in each browser; this should help us write nicer CSS with fewer hacks too
* font sizing - platform and browser dependent and accessible font sizing - looks like a good idea
* CSS for each YUI widget - does not interfere with any other CSS
* YUI CSS Grids - does not interfere with other CSS, it is used only if you specify class attribute
4.) Can you explain the difference between the "layout templates" in layout/ and the "templates" that will go into template/?
* layout - the whole page layout - divides page into areas like header, navigation, blocks, footer, main content - mostly html layout, some PHP logic - here we need the column layouts, here we could use YUI Grids or anything else - it is just the choice of Theme designer
* renderer - programatic construction of HTML code - such as printing of headers or tabs - a lot of PHP logic is included
* template - kind of bigger html fragment, something like visualisation of forum post, may include some PHP, simple types may contain only html markup and some variables
This is not explained much in my proposal, because I am still working on this part - discussing it with David, studying Tim's proposal, trying to come with some new solutions.
6.) Meta.php
Browser specific body class was the only technical solution I found that allows us to put themes into dataroot or any other place that is not accessible via web. And yes, you may still use a separate file for these hacks - the difference is you need to include the .ie7/.ie6 modifiers
7.) Themes in dataroot - ... edited directly through the Moodle interface...>
My -1, editing of any CSS or file in downloaded theme create big upgrade and maintenance problems - exactly the kind of problems we have now - I think using more theme settings is better solution for administrators. Please note that the recommended step for each major upgrade is to copy just main config.php and then download fresh versions of everything including the themes - if you have modified something you usually loose tweaks or may have conflicts if cvs used.
8.) Few themes in the official distribution: I've been asked to create 20 new themes to be shipped with 2.0. I can certainly see the appeal of cutting this down to, say, 3 themes as you've suggested, as long as their is a web interface to preview and download themes inside Moodle.
However, the database providing the themes seen through this interface should not be the one located at http://moodle.org/mod/data/view.php?id=6552. A separate database containing only regularly updated, officially supported themes should be used instead.
Installing and updating of themes is very problematic now, that is probably the reason why Martin wanted so many of them - and I agree we do need many of them, the question is where to have them. And yes, I agree we have to do something with our contrib - more quality review, ratings, recommendations, etc.
Thank you for the more thorough description of how the YUI CSS and layouts would work. It all sounds great to me.
If I understand correctly from the above, the only items from the theme that would be stored in dataroot would be the items changed via the admin interface using settings.php?
If I understand correctly from the above, the only items from the theme that would be stored in dataroot would be the items changed via the admin interface using settings.php?
No, it would be possible to store complete themes there (all the config.php. styles*.css, lib.php, etc). In fact it does not have to be in dataroot - any directory on the server would work. We would have similar interface to the current language pack import tool. It does not have to have to be writable either, admins should be able to configure this.
The settings are stored in config_plugins table, images could be supplied as external links pointing anywhere, but later there should be also the option to use real moodle files (the problem is we do not have any admin setting classes that work with the new filesystem in 2.0dev).
The settings are stored in config_plugins table, images could be supplied as external links pointing anywhere, but later there should be also the option to use real moodle files (the problem is we do not have any admin setting classes that work with the new filesystem in 2.0dev).
Just to say that I read one of the drafts of Petr's proposals, and my response was: "Seems like I good idea to me, but I am much more interested to know what the people in the themes forum think than what I think."
This thread seems to be an excellent discussion of the issues, so I will continue to read it with interest.
(P.S. This is my first day back at the OU. Having just moved into a new flat, I don't currently have internet at home.)
This thread seems to be an excellent discussion of the issues, so I will continue to read it with interest.
(P.S. This is my first day back at the OU. Having just moved into a new flat, I don't currently have internet at home.)
Hello,
I have uploaded the theme prototype onto my test server, you may get a copy of thr modified cvs checkout from MDL-20204 (the patch was too big and it would not work for changed binary files anyway).
So far it seems to work as expected, if you are interested in theme design please have a look at the sample theme that is included (YUI grid layout, settings, etc.).
Petr
I have uploaded the theme prototype onto my test server, you may get a copy of thr modified cvs checkout from MDL-20204 (the patch was too big and it would not work for changed binary files anyway).
So far it seems to work as expected, if you are interested in theme design please have a look at the sample theme that is included (YUI grid layout, settings, etc.).
Petr
Manuo discovered one major IE problem, the one big CSS hits the 4096 selector limit in IE Can be solved by some nasty hack I guess.
While looking at the CSS I realised that our CSS structuring to separate styles for layout, color and fonts is a bit non-standard. Also the standard and contrib modules are in a completely different situation - the core modules have their CSS in standard theme.
What would theme designers thing about this proposal?:
1) move module and other plugin css into plugins (ex: mod/forum/styles.css)
2) merge layout, fonts and colours
3) add new standard stylesheets - some logical chunks such as admin, layout
My reasons are:
1/ the main theme layout file is getting too big
2/ I do not like the separation of plugin css from the plugin
3/ we might better separate the sheets for each independent part of moodle - such as style_admin.css
4/ page layout should be in separate sheet - so that it is easier to maintain and override (I already tried that in my prototype) - previously this was a performance problem, but now the situation is different
Ideas? Objections?
While looking at the CSS I realised that our CSS structuring to separate styles for layout, color and fonts is a bit non-standard. Also the standard and contrib modules are in a completely different situation - the core modules have their CSS in standard theme.
What would theme designers thing about this proposal?:
1) move module and other plugin css into plugins (ex: mod/forum/styles.css)
2) merge layout, fonts and colours
3) add new standard stylesheets - some logical chunks such as admin, layout
My reasons are:
1/ the main theme layout file is getting too big
2/ I do not like the separation of plugin css from the plugin
3/ we might better separate the sheets for each independent part of moodle - such as style_admin.css
4/ page layout should be in separate sheet - so that it is easier to maintain and override (I already tried that in my prototype) - previously this was a performance problem, but now the situation is different
Ideas? Objections?
The current standard theme css has grown very heavy and many tags are defined several times in different files - and we have lots of these new tags for new activities, tinymce, yui, ...
Because different activities are not loaded at the same time it sounds reasonable to take module and plugin css to activities - can moodle allow you to add the activity css folders inside theme folder so that if you want to modify css for forum it can be done with css file inside mod/forum folder or custom theme/mod/forum folder with some $CFG setting? Or do we use $THEME->pluginsheets = array(...); if plugin css is not defined in other css ?
Many pages like http://www.dailycoding.com/Posts/top_7_tip_for_optimizing_css.aspx and http://www.sohtanaka.com/web-design/optimizing-css-tutorial/ have some examples for optimizing and grouping css tags further.
There are some good reasons for separating css to layout, color and fonts like http://www.alistapart.com/articles/progressiveenhancementwithcss/ - css of moodle is well grouped but there are just too many of those different css tags - css could be collected and combined to smaller number of tags. Any volunteers?
One "easy solution" could be also to give IE a totally different set of "IE rules" or after reset code just give the most necessary css tags for IE in a separate css file that only IE loads - only because IE is the only browser that has those css limits like 4096 selector limit
Petr,
I appreciate your proposal to separate the CSS into logical chunks. It suits modularity very well. And in logical chunks layout, color and fonts together make sense.
All your topics 1) - 3) and 1/ - 4/ agreed.
Layout, colors, fonts
There needs to be a clear separation between the basic page layout (where and how the page elements are presented on the individual page) on one side and consistent use of fonts and colors on the other side. Fonts and colors should mainly be set up in the theme. Page layout makes sense in the module CSS. Too much CSS in modules will create a whole mess. Good documentation is needed here.
Override or replace CSS
In the theme we need to be able to turn off the module CSS and replace it with CSS in the theme. The modular approach should not lead to more lines of CSS delivered to the browser.
When the main layout CSS from standard is always included in every theme pages can't break. All other CSS could be turned of / replaced to avoid too many CSS definitions overriding each other.
Separate CSS files delivered in "theme designer mode"
And the in "theme designer mode" Moodle should continue to deliver every CSS file separately to the browser as it does in 1.9 when the CSSEdit option is active. Only with this option tools like CSSEdit, Espresso and others can be used. They connect CSS in the preview pane delivered in the page with CSS files on the hard-disk. 1:1 mapping is needed. You can edit CSS locally in the mapped files and all changes immediately are presented in the preview pane. This way the number of CSS files you work with is no issue.
New base theme and "Standard" building on "Base"
I propose to think about a new strategy for a "Base" theme and a "Standard" theme. The "Standard" theme is active when you install Moodle. It is a "designed" theme. The "Base" theme in the opposite holds the minimum of the CSS necessary that pages don't break. "Base" is actively maintained by the developers. Important is to keep the need to override CSS at a minimum in the whole system. Then all themes can build on "Base" with relatively few CSS definitions and not on a full designed "Standard" theme with many CSS definitions they need to override.
Cleaned up and reduced CSS in "Base" theme
The "Base" theme should be set up with the bare minimum of CSS. For example the middle alignment does not make sense. Default for left-to-right languages is left aligned and default for right-to-left is right aligned. If you don't set alignments in CSS the browsers handle the differences automatically.
The "Base" theme should set exactly one font size for all text, links, tables etc. etc. together. Plus the sizes for h1 - h6. More differentiation should be added in themes where appropriate and when necessary.
With good hooks in the XHTML we can set the CSS for different designs in the theme CSS. Which is much better than to override "wrong" CSS as in 1.9 themes.
CSS delivery to the browser
"Base" CSS and all modules CSS may be grouped together in one CSS file and all theme CSS may be grouped together in another CSS file.
A lot of great stuff here. I don't disagree. I would like to add some support for a stripped-down base theme:
Every theme that I create a new theme, it includes my own default reset of Standard values. For example:
h2.headingblock {border-width:0 0 1px 0;}
.coursebox {border-width:0 0 1px 0; padding-bottom:10px;}
.categorybox {border:none;}
I could go on as this is but a small chunk of what I do from memory.
It would be great if we had a true base theme. I think that Base should continue to be Standard (stripped down to bare essentials), and the theme users see when they install Moodle should be called something else (like Default or Sandwich or whatever).
Separating module CSS into module stylesheets: It doesn't bother me as long as those stylesheets can be overridden at the theme level. I think it's a great idea.
Putting styles_layout.css, styles_color.css, and styles_fonts.css together: I've never liked this setup even if it is logical. I like to see all rules for a given element in one place. Therefore, it makes more sense to divide sheets by function (styles_admin.css, styles_frontpage.css, etc.).
Every theme that I create a new theme, it includes my own default reset of Standard values. For example:
h2.headingblock {border-width:0 0 1px 0;}
.coursebox {border-width:0 0 1px 0; padding-bottom:10px;}
.categorybox {border:none;}
I could go on as this is but a small chunk of what I do from memory.
It would be great if we had a true base theme. I think that Base should continue to be Standard (stripped down to bare essentials), and the theme users see when they install Moodle should be called something else (like Default or Sandwich or whatever).
Separating module CSS into module stylesheets: It doesn't bother me as long as those stylesheets can be overridden at the theme level. I think it's a great idea.
Putting styles_layout.css, styles_color.css, and styles_fonts.css together: I've never liked this setup even if it is logical. I like to see all rules for a given element in one place. Therefore, it makes more sense to divide sheets by function (styles_admin.css, styles_frontpage.css, etc.).
Hello and thanks a lot for all your feedback!!
I was working on the themes more today, fixed following:
* IE 4096 trouble solved by splitting CSS into 4 sheets and including them from the main CSS - it means we still have only one CSS in the page
* added separate theme/styles_debug.php that serves each script separately in designer mode - we can not load the scripts directly from their locations because we need to postprocess CSS and get the files from dataroot
* added cache reset button to theme selection page
* a bit more refactoring and cleanup
IE hacks - we can not put them into separate files and load them only for IE because they need to be loaded in correct order - not compatible with the "one huge CSS" design; so far my brute force hackign with .ie6 seems to work fine.
I am going to upload new package to my test server later tonight and announce it here.
I will try to discuss the base theme idea with Martin tomorrow, thanks for all your support again
Petr
I was working on the themes more today, fixed following:
* IE 4096 trouble solved by splitting CSS into 4 sheets and including them from the main CSS - it means we still have only one CSS in the page
* added separate theme/styles_debug.php that serves each script separately in designer mode - we can not load the scripts directly from their locations because we need to postprocess CSS and get the files from dataroot
* added cache reset button to theme selection page
* a bit more refactoring and cleanup
IE hacks - we can not put them into separate files and load them only for IE because they need to be loaded in correct order - not compatible with the "one huge CSS" design; so far my brute force hackign with .ie6 seems to work fine.
I am going to upload new package to my test server later tonight and announce it here.
I will try to discuss the base theme idea with Martin tomorrow, thanks for all your support again
Petr
hehe, this all sounds like a big theme revolution is coming up in Moodle 2.0 
I can not wait till I start with editors again
I can not wait till I start with editors again
updated, I have one new idea how to simplify life of theme and contrib plugin developers:
Allow putting of two types of stylesheets into plugins - first the styles.css (loaded before the theme sheets) and then theme/themename.css which is loaded as the last sheet - this would allow contib plugin such as book to add proper theme specific sheets to any official or contrib theme.
Petr
Allow putting of two types of stylesheets into plugins - first the styles.css (loaded before the theme sheets) and then theme/themename.css which is loaded as the last sheet - this would allow contib plugin such as book to add proper theme specific sheets to any official or contrib theme.
Petr
Sounds good and looks good already...
One question is also what to do with IE8 - does it need some extra .ie8 tags as well - or should we prefer .ie when ever it is possible?
As a tiny example if we have in current css
.ie6 .sideblock .block_tree,
.ie7 .sideblock .block_tree {
overflow-x:scroll;
}
it could be shorter
.ie .sideblock .block_tree {
overflow-x:scroll;
}
or if we don't need that scrollbar (why is it shown there in navigation block for IE?)
.ie .sideblock .block_tree
{
overflow-x:hidden;
}
Or if we don't need that scrollbar the whole tag could be removed (block_tree is a div tag so IE should not render scrollbar by default...)
One question is also what to do with IE8 - does it need some extra .ie8 tags as well - or should we prefer .ie when ever it is possible?
As a tiny example if we have in current css
.ie6 .sideblock .block_tree,
.ie7 .sideblock .block_tree {
overflow-x:scroll;
}
it could be shorter
.ie .sideblock .block_tree {
overflow-x:scroll;
}
or if we don't need that scrollbar (why is it shown there in navigation block for IE?)
.ie .sideblock .block_tree
{
overflow-x:hidden;
}
Or if we don't need that scrollbar the whole tag could be removed (block_tree is a div tag so IE should not render scrollbar by default...)
Never mind my last comment - default value for overflow seems to be "visible" - there was just similar tag with auto property just before ie css...
.sideblock .block_tree {
width:180px;
overflow-x:auto;
overflow-y:visible;
}
.ie6 .sideblock .block_tree,
.ie7 .sideblock .block_tree {
overflow-x:scroll;
}
http://css-tricks.com/the-css-overflow-property/
This new navigation tree looks both interesting and a little "spreading" at the same time...
One more comment to this tiny issue - I started to test a custom theme with more settings and if we allow themes to select block width we should allow content of blocks to change width according to outer block. In styles_layout.css of custom theme at least
.sideblock .block_tree {
width:180px;
overflow-x:auto;
overflow-y:visible;
}
could be changed to
.sideblock .block_tree {
width:100%;
overflow-x:auto;
overflow-y:visible;
}
See attached image for reasons.
Petr,
I must say that this new way to set themesettings and background images to theme css with expressions like background-image:url([[pix:theme|bg_top2]]); is one of the coolest things I have ever used...
Design mode really makes pages slower so I will probably use it only if I make big changes to themes offline (using local test box)
Should we have some different tracker issue for standard theme css suggestions? Small things pop up all the time - for example
.block_adminblock {
width: 180px;
}
could be changed
.block_adminblock {
width: 100%;
}
.menujump {
width: 100%;
margin-bottom:10px;
}
or something like that
(current Add blocks - block is 180px although you can set the width of other blocks.)
Should we drop 'styles_moz' from standard theme config.php? Otherwise standard theme looks different depending on browser ( particularly FF and IE ).
It is in any case possible to use round corners either with that css file or with other custom css in custom themes. If round bottom corners are not used that bottom-margin for menujump is not needed either.
I tested custom themes during the weekend and one interesting "bug" is that theme selector seems to pick same screenshot for all themes.
Otherwise creating and customizing new themes looks both easier and more fun with new features than with old themes. It just takes some time to learn the logic behind new themes...
Hello,
I have spent the last few days messing with CSS multi column layouts, moving all existing CSS into Standard theme and trying to create some new sample "base" theme and one new minimalistic experimental theme.
It was a lot of hair pulling and screaming, there seems to be so much ancient CSS and very many hacks in the standard theme, the markup we create in some places is not nice at all.
I am personally starting to think we should start from scratch with new CSS and fix the markup we create in code. I was wondering how long would it take to create the base theme (CSS needed only for JS tricks such as the hiding, basic layout, no colours, no font sizes) and new "default" theme that replaces the old standard white.
The problem with maintaining of old table layout standard is that once we fix the markup it gets broken and our old hacks make fixing it more problematic.
Petr
I have spent the last few days messing with CSS multi column layouts, moving all existing CSS into Standard theme and trying to create some new sample "base" theme and one new minimalistic experimental theme.
It was a lot of hair pulling and screaming, there seems to be so much ancient CSS and very many hacks in the standard theme, the markup we create in some places is not nice at all.
I am personally starting to think we should start from scratch with new CSS and fix the markup we create in code. I was wondering how long would it take to create the base theme (CSS needed only for JS tricks such as the hiding, basic layout, no colours, no font sizes) and new "default" theme that replaces the old standard white.
The problem with maintaining of old table layout standard is that once we fix the markup it gets broken and our old hacks make fixing it more problematic.
Petr
Hi Petr,
Unfortunately I don't have the time to look into it myself but here are some links to proven Drupal starter themes:
http://adaptivethemes.com/starter-theme-comparison.html
http://adaptivethemes.com/drupal-starter-themes-test-site-rocks (offline at the moment)
http://www.chapterthree.com/blog/squiggy_rubio/review_drupal_6_starter_themes
The most prominent of those is ZEN a theme which allows nearly complete customization by CSS (http://drupal.org/project/zen).
hth
Frank
Unfortunately I don't have the time to look into it myself but here are some links to proven Drupal starter themes:
http://adaptivethemes.com/starter-theme-comparison.html
http://adaptivethemes.com/drupal-starter-themes-test-site-rocks (offline at the moment)
http://www.chapterthree.com/blog/squiggy_rubio/review_drupal_6_starter_themes
The most prominent of those is ZEN a theme which allows nearly complete customization by CSS (http://drupal.org/project/zen).
hth
Frank
Petr,
It was a lot of hair pulling and screaming, there seems to be so much ancient CSS and very many hacks in the standard theme, the markup we create in some places is not nice at all.
"hair pulling and screaming" is what I've been doing for some years now when designing for Moodle. You may (better) understand my view now.
Your proposal to start from scratch and fix the markup will be the best way forward. How long this job will take depends mainly on a good base concept for the Moodle page XHTML structure and it's variations, the CSS and JS hooks and XHTML and CSS know-how.
One aspect of the base concept will be to decide if the XHTML structure and the CSS must work
1) for many different layout variants you can add with CSS :: complex and that means difficult for the needed high flexibility
2) for one layout. Variations will be implemented with different XHTML structures (via templates) :: simple and relatively easy
2) is my favorite. 1) may be implemented on top of 2) with a set of templates but not as the main solution.
hmmm, we do have high level templates already in my proposal - they are called page layouts. Tim designed just a few of them I would vote for much more, namely: course, home, login, module, form, mymoodle, admin, profile, and some more. These lay out the header/footer/columns and fancy stuff around it such login and home links.
The rendering of "#content" (== the middle column) is a different problem imho - there are two options - renderers (functions) or templates(files). I have implemented both in my prototype, the coder decides which one to use. The code can be pretty much the same but the API is different. I do think this it would be possible to use templates everywhere, but I agree there are some places where templates make much better sense.
So back to your 1/ or 2/ question - I would vote for:
* fixing old markup to use new recommended CSS based layouts
* create the "base" theme with real functional minimum that just allows the JS and accessibility tweaks to work (such as the new collapsible navigation tree, hidden skip to links)
* create new "developers" theme which is managed by deveopers
* create new "default" theme designed and maintained by theme designers (default for installation)
* and finally tens of beautiful and fully configurable themes
Now back to templates and renderers, I think the template makes sense in following areas for example:
* login page
* some blocks
* course listing widgets on the frontpage
My major objection against the templates is the high maintenance costs, any change in template will have to be replicated to all themes that changed this template - the theme designers will not notice this, somebody will have to notify them. Custom theme renderers would have the same problems, the more easier it is to replace core layouts/renderers the more headaches the more headeaches for developers who need to change anything.
The beauty of pure CSS themes is that it may actually work even after we tweak/change the markup - so a clear winner for me is CSS only themes + custom images + tweaked page layout files (now speaking as both administrator and developer).
I am not really sure if templates are the best way forward - in any case if we fix our markup now and create good base + default CSS in themes this does not prevent us from introducing the templates in future - in fact that step would be fully backwards compatible.
Petr
The rendering of "#content" (== the middle column) is a different problem imho - there are two options - renderers (functions) or templates(files). I have implemented both in my prototype, the coder decides which one to use. The code can be pretty much the same but the API is different. I do think this it would be possible to use templates everywhere, but I agree there are some places where templates make much better sense.
So back to your 1/ or 2/ question - I would vote for:
* fixing old markup to use new recommended CSS based layouts
* create the "base" theme with real functional minimum that just allows the JS and accessibility tweaks to work (such as the new collapsible navigation tree, hidden skip to links)
* create new "developers" theme which is managed by deveopers
* create new "default" theme designed and maintained by theme designers (default for installation)
* and finally tens of beautiful and fully configurable themes
Now back to templates and renderers, I think the template makes sense in following areas for example:
* login page
* some blocks
* course listing widgets on the frontpage
My major objection against the templates is the high maintenance costs, any change in template will have to be replicated to all themes that changed this template - the theme designers will not notice this, somebody will have to notify them. Custom theme renderers would have the same problems, the more easier it is to replace core layouts/renderers the more headaches the more headeaches for developers who need to change anything.
The beauty of pure CSS themes is that it may actually work even after we tweak/change the markup - so a clear winner for me is CSS only themes + custom images + tweaked page layout files (now speaking as both administrator and developer).
I am not really sure if templates are the best way forward - in any case if we fix our markup now and create good base + default CSS in themes this does not prevent us from introducing the templates in future - in fact that step would be fully backwards compatible.
Petr
True - these new layout files work really well and they are perfect for changing design for those different parts of moodle.
From "normal moodler's point of view" the main problem seems to be the huge number of small details in standard theme css.
For example I just checked that tiny change to standard theme to make block width of block_adminblock equal to other blocks (100%) and the code to change width of menujump to 100% as well...
This actually changed also course area css and I had to change the latter part to
.sideblock .menujump {
width: 100%;
}
to make that change happen only for sideblocks. I was not satisfied to this result and tried next
.block_adminblock .menujump {
width: 100%;
}
Next trial:
.sideblock .menujump {
width: 80%;
}
.block_adminblock, .block_adminblock .menujump {
width: 100%;
}
and what do I see - different font sizes... 
Standard theme styles_layout.css is full of such tiny details that people have added during the past years to make standard theme functional in different parts of moodle and most current custom themes use this file - even if they use custom colors and fonts and may exclude other standard theme files. As such current styles_layout.css is rather stable.
We probably could try to make standard sideblock structure more "standard" so that all blocks have similar settings for common parts of blocks like header, content and footer - unless some block (like calendar) requires different css from block custom css - because page can have many blocks. We could at the same time offer more optional layouts in theme selector - not 20 similar standard layouts with different colors, fonts and images. With settings.php it is possible to offer those 20 theme color/font/logo variants with one single theme.
If most activity css is moved to each activity and loaded only with each activity it sounds like a big ++
If some essential parts of css can be optimized to minimal number of "standard tags" (styles_layout_min.css) it is a big ++
If some tiny additional things (margins, paddings, alignments, colors, fonts, borders) can be defined after reset css to actual styles_layout.css (all tags) or optionally together with styles_layout_min.css to styles_layout_custom.css it's more ++
And finally - if we get tens of beautiful and fully configurable themes...all kinds of nice looking themes...it's a huge +++++
One problem with changing tables to divs is seen for example in different course formats. Moodle 1.9 is using tables in Topics format and moodle 2.0 is using divs.
Because boxes for topics are too low all icons on the right don't fit to box and overlapping causes a funny effect. With tables such things never happen because height and width of cells are automatically changed (unless they are fixed). This is not visible in Weekly format because weekday makes box one line higher...
So either standard theme should use smaller icons or css for Topics format should use heigher default boxes...or code of course format Topics should somehow check that all content fits to box...
Although tables are often said to be bad for anything but for tabular data they have some good points and creating site css that works perfectly well with both table layout and div layout at the same time may be rather difficult...
Just for the curious who want to have a look at the underlying markup for the course categories in Moodle 1.9:
"Course Categories - The Ugly Duckling"
http://docs.moodle.org/en/User:Frank_Ralf/Semantic_HTML3
"Course Categories - Clearing the Tables"
http://docs.moodle.org/en/User:Frank_Ralf/Semantic_HTML4
Admittedly I haven't looked at the problem of the edit icons yet.
Cheers,
Frank
"Course Categories - The Ugly Duckling"
http://docs.moodle.org/en/User:Frank_Ralf/Semantic_HTML3
"Course Categories - Clearing the Tables"
http://docs.moodle.org/en/User:Frank_Ralf/Semantic_HTML4
Admittedly I haven't looked at the problem of the edit icons yet.
Cheers,
Frank
Nice examples, Frank!
I wonder if different course formats should have custom css in separate course format css files like Petr is planning to move css of activities to activity level.
In practise we could have many more course formats and we only use one course format at a time so keeping different tags for weekly format, topics format, table layout, non table layout etc in a same file (styles_layout.css) increases the number of "extra tags" again...
Even if the number of css files and this way number of http requests might be higher length of main css would be shorter and again easier to target modifications to each course format separately.
oh, that is not what I proposed - I proposed to always load all CSS files from all plugins. That means we would have to fix all CSS selectors - all we need is a div with class "courseformat_weeks" around this area.
Core plugins would probably have the styles in separate file directly in base and default theme, but contrib coursepage layouts would have it in styles.css and the theme/themename.css files. In fact the contrib coursepage format authors might decide to use true templates.
Core plugins would probably have the styles in separate file directly in base and default theme, but contrib coursepage layouts would have it in styles.css and the theme/themename.css files. In fact the contrib coursepage format authors might decide to use true templates.
Thanks for the clarification, Petr... 
I'll take some coffee now before continuing theme testing...
Petr, one a little confusing thing in your samplecolor demo theme was that block widths were taken from yui grid css but the given values in settings (administration) were not the same as yui grid values and setting values were not given in samplecolor theme styles css...
It was however good (instructive experience) to take a closer look to grids css, #doc3 etc - all sorted now ...
My template_renderer (lib/outputrenderers.php) and template_renderer_factory (lib/outputfactories.php) classes were ment to be a proof of concept that renderers were sufficient to implement templates with very little additional code - although I am pretty sure it needs debugging to make it actually work.
I like all the basic ideas in current theme plan but I could create one more prototype theme that can be used with ThemeRoller. See http://moodle.org/mod/forum/discuss.php?d=135473 and http://jqueryui.com/themeroller/
Can I get a ballpark status update on these updates. I put off creating any new themes for 2.0 until everything was solid again. I'm not a programmer, but would love to help. Is there any HTML/CSS work or testing I can do?
I think it is the next thing on Petr's list after what he is currently working on (web services), so with luck a couple of weeks.
Patrick "Can I get a ballpark status update on these updates."
What does that mean?
Joseph
What does that mean?
Joseph
I was testing yesterday some totally different kinds of layouts - without YUI Grids - and one interesting solution was to combine fluid 3 column div layout and scalable font sizes according to detection of window width. Php itself can't change layout dynamically so I used a very simple jquery script to select different default font size (class) for different screen widths and if javascript is disabled default settings were used. All margins, paddings, widths etc were defined using em or % - only default font size was defined as px (14px) - this way the same theme can be used from 300 px smart phones to large screens and basic layout looks almost similar with all resolutions. Also logos, buttons and icons can be set to use different css but resizing of custom images (course content added by users) is of course rather difficult...
One new odd thing was that selecting session themes seemed to break totally css - does this mean that you are going to change also theme switcher system, Petr?
I am fully in support of this, especially the YUI CSS to reset fonts and margins.
Echoing the statements above, I would like the YUI Grids to be optional as I do most of my layout manually with a flexible design.
Echoing the statements above, I would like the YUI Grids to be optional as I do most of my layout manually with a flexible design.