Urs Hunkler

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.

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!

Thanks Martin,

so you took 1 AND 2. For me the best way to continue will be to look at Tim's Implementation once it is ready and work from there.

One example for a contrary designer versus developer approach:
In my actual themes I use 3 templates for the <div id="header"> part - one for "header-home", one for "header" and one for "header-minimal". Lots of redundant code. Since I use this approach I clearly see at one glance how the header is built and can work in changes easily and fast. I don't mind copying the code over to the other templates.

With the code reduction approach in the normal theme header <div id="header"> part I always needed to think and try a lot before I could get the header changes working.

With the different templates approach I am faster and feel much more in control than with the code reduction approach. I can do my work more efficiently.

Tim makes the world more complicated when he thinks his developer view is the only and best way to go. Very, very wrong And his way of telling us that everything except his opinion is stupid is not very helpful either.

And Martin, your maintenance example shows a developer oriented development approach. User oriented approaches are needed for superior products.

@Martin Dougiamas

Martin please give a clear statement about the Moodle theme strategy. People looking into Moodle theme work will know what to expect and developers know how to plan theme related code.

Shall Moodle Themes be 1. easy to work with for designers 2. program code like all other scripts

If you declare 1. as the main focus for themes Moodle developers must stop to treat themes like other Moodle code and engage more to understand designer's needs.

If you declare 2. as the Moodle way to handle themes I'll cry and will stop to further argue.