Moodle in English: Yet more theme changes proposal

Re: Yet more theme changes proposal

by Urs Hunkler - Thursday, 3 September 2009, 9:54 PM

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.

Average of ratings: Useful (1)

Re: Yet more theme changes proposal

by Patrick Malley - Thursday, 3 September 2009, 11:53 PM

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.).

Average of ratings: -

Re: Yet more theme changes proposal

by Petr Skoda - Friday, 4 September 2009, 3:55 AM

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

Average of ratings: -

Re: Yet more theme changes proposal

by Petr Skoda - Friday, 4 September 2009, 4:05 AM

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

Average of ratings: -

Re: Yet more theme changes proposal

by Petr Skoda - Friday, 4 September 2009, 3:01 PM

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

Average of ratings: -

Re: Yet more theme changes proposal

by Mauno Korpelainen - Friday, 4 September 2009, 5:39 PM

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...)

Average of ratings: -

Re: Yet more theme changes proposal

by Mauno Korpelainen - Friday, 4 September 2009, 7:58 PM

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...

Average of ratings: -

Re: Yet more theme changes proposal

by Mauno Korpelainen - Friday, 4 September 2009, 10:23 PM

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.

Average of ratings: -

Re: Yet more theme changes proposal

by Mauno Korpelainen - Saturday, 5 September 2009, 1:49 PM

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.

Average of ratings: -

Re: Yet more theme changes proposal

by Mauno Korpelainen - Monday, 7 September 2009, 2:17 PM

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...

Average of ratings: -

Re: Yet more theme changes proposal

by Petr Skoda - Monday, 7 September 2009, 5:30 PM

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

Average of ratings: -

Re: Yet more theme changes proposal

by Frank Ralf - Monday, 7 September 2009, 6:44 PM

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

Average of ratings: -

Re: Yet more theme changes proposal

by Urs Hunkler - Monday, 7 September 2009, 7:01 PM

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.

Average of ratings: -

Re: Yet more theme changes proposal

by Petr Skoda - Monday, 7 September 2009, 8:39 PM

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

Average of ratings: -

Re: Yet more theme changes proposal

by Mauno Korpelainen - Tuesday, 8 September 2009, 1:02 AM

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... wide eyes

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 +++++

Average of ratings: -

Re: Yet more theme changes proposal

by Mauno Korpelainen - Tuesday, 8 September 2009, 2:34 PM

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...

Average of ratings: -

Re: Yet more theme changes proposal

by Frank Ralf - Tuesday, 8 September 2009, 3:45 PM

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

Average of ratings: Useful (1)

Re: Yet more theme changes proposal

by Mauno Korpelainen - Tuesday, 8 September 2009, 4:16 PM

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.

Average of ratings: -

Re: Yet more theme changes proposal

by Petr Skoda - Tuesday, 8 September 2009, 5:10 PM

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.

Average of ratings: -

Re: Yet more theme changes proposal

by Mauno Korpelainen - Tuesday, 8 September 2009, 5:37 PM

Thanks for the clarification, Petr...

I'll take some coffee now before continuing theme testing... big grin

Average of ratings: Useful (1)

Re: Yet more theme changes proposal

by Mauno Korpelainen - Wednesday, 9 September 2009, 8:52 PM

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 ...

Average of ratings: -

Re: Yet more theme changes proposal

by Tim Hunt - Thursday, 17 September 2009, 12:50 AM

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.

Average of ratings: -

Re: Yet more theme changes proposal

by Mauno Korpelainen - Monday, 19 October 2009, 9:32 AM

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/

Average of ratings: -

Re: Yet more theme changes proposal

by Patrick Malley - Thursday, 22 October 2009, 9:41 PM

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?

Average of ratings: -

Re: Yet more theme changes proposal

by Tim Hunt - Sunday, 25 October 2009, 6:48 PM

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.

Average of ratings: -

Re: Yet more theme changes proposal

by Joseph Rézeau - Sunday, 25 October 2009, 8:51 PM

Patrick "Can I get a ballpark status update on these updates."
What does that mean? mixed

Joseph

Average of ratings: -

Re: Yet more theme changes proposal

by Tim Hunt - Sunday, 25 October 2009, 9:18 PM

See http://en.wiktionary.org/wiki/ballpark_figure

Average of ratings: Useful (3)

Re: Yet more theme changes proposal

by Mauno Korpelainen - Monday, 14 September 2009, 2:42 AM

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?

Average of ratings: -