I spent a lot of time this weekend working on my Boxxie theme, which will be included in the core. This is basically my 1.9 theme "Greenie" renamed to accommodate difference colors down the road. The amount of time I invested was silly and I still haven't made it through all of the modules. There's clearly a lot of work yet to do on the base theme. Or, is there?
A lot of issues I found myself fixing were in relation to layout and structure. Here are my biggest question:
1.) As I work through my themes, should I be basing them on just "base" or should I base them of both base and Standard?
If the latter, then why have a base?
If the Base theme is to be a starter theme, it should include all essential styles to make the installation work correctly. If the Base theme is to be the starter theme, then I know I'll just add my fixes to it as I work this summer. Others can file bugs for me to fix it if necessary as they find it. This way, I won't have to update 20 themes with one fix down the road. Right?
One more question:
2.) Should module and block layout issues be resolved in their own styles.css file? I'm pretty sure the answer here is yes, but I thought I should ask.
Hi Patrick,
We appreciate the effort you are putting into theming for making our life simpler with Moodle 2.0 themes. Thank you :)
I dont know if its easy to do. But IMO i think we should have two themes with Moodle 2.0 beta release. One can be a very minimal theme with only needed settings(a base theme to start with) and the other making use of all or atleast most of the features of Moodle 2.0 theming. Just to show what can be done with MDL 2 themes and how to exploit it to our advantage. It will only invite more innovation and good work from fellow themers, developers and UI artists!!
IMHO fixing a lot many themes with the same fix when in beta will be an extra job to do, specially in beta (and before) when the code is changing very frequently. Can we not save it for later?
We can have more themes once MDL2 themes have become somewhat concrete in shape. What say?
And yes, if there is anything that I can help you with, do let me know I will be glad to do that :) I am working on MDL 2.0 themes myself and curve has been steep but good. Thanks to the very active community.
#2. Yes. It will be nice to leave it with what you ve suggested. It seems a wise option to go with.
Cheers!!
--
Nave
We appreciate the effort you are putting into theming for making our life simpler with Moodle 2.0 themes. Thank you :)
I dont know if its easy to do. But IMO i think we should have two themes with Moodle 2.0 beta release. One can be a very minimal theme with only needed settings(a base theme to start with) and the other making use of all or atleast most of the features of Moodle 2.0 theming. Just to show what can be done with MDL 2 themes and how to exploit it to our advantage. It will only invite more innovation and good work from fellow themers, developers and UI artists!!
IMHO fixing a lot many themes with the same fix when in beta will be an extra job to do, specially in beta (and before) when the code is changing very frequently. Can we not save it for later?
We can have more themes once MDL2 themes have become somewhat concrete in shape. What say?
And yes, if there is anything that I can help you with, do let me know I will be glad to do that :) I am working on MDL 2.0 themes myself and curve has been steep but good. Thanks to the very active community.
#2. Yes. It will be nice to leave it with what you ve suggested. It seems a wise option to go with.
Cheers!!
--
Nave
Hi Patrick,
In answer your questions...
1. I feel that BASE theme should be the main theme which all themes are based on. Do away with any reference to Standard Theme, this together with any reference to old design structures should be banished from Moodle 2.0, otherwise everyone will be confused. Might as well start as we mean to go on. If I am to try and update the Moodle 2.0 Docs, especially with respect to Customising Themes, it would be good to know now what is going to be the 'benchmark' to work from. Base Theme seems a logical choice.
2. Yes...I agree with you on this.
I commend you for all the time and effort you are putting into this, it is no mean feat, it is an awesome task you have undertaken!
Mary
In answer your questions...
1. I feel that BASE theme should be the main theme which all themes are based on. Do away with any reference to Standard Theme, this together with any reference to old design structures should be banished from Moodle 2.0, otherwise everyone will be confused. Might as well start as we mean to go on. If I am to try and update the Moodle 2.0 Docs, especially with respect to Customising Themes, it would be good to know now what is going to be the 'benchmark' to work from. Base Theme seems a logical choice.
2. Yes...I agree with you on this.
I commend you for all the time and effort you are putting into this, it is no mean feat, it is an awesome task you have undertaken!
Mary
It looks like Standard is sticking around, but only as one of many other theme options.
Per my understanding and Martin's comments below: you can use any theme as a parent theme. I will be basing all of my initial core themes on Base alone. I advise you to do the same until we get some more themes in place. Then, let's say you like Boxxie, but want to see it in Magenta and with a different layout, then you can do that with Boxxie as a parent.
The documentation should be clear on this flexibility to choose any theme as a parent.
Hope that's more clear.
Per my understanding and Martin's comments below: you can use any theme as a parent theme. I will be basing all of my initial core themes on Base alone. I advise you to do the same until we get some more themes in place. Then, let's say you like Boxxie, but want to see it in Magenta and with a different layout, then you can do that with Boxxie as a parent.
The documentation should be clear on this flexibility to choose any theme as a parent.
Hope that's more clear.
Boxxie is looking really nice already Patrick - I'm using it! (Since the first one was Anomaly I have been wondering if you are planning to work your way through the alphabet 
)
1. You can use any core theme to base a new one on.
Base is a real bare-bones theme with basic layout only, no colors etc. It's a better basis for creative themes where you plan a lot of changes and don't want to be overriding styles all the time (as people used to have to do in 1.9). It's not really designed to be usable as a theme itself. And yes we should be correcting obvious layout problems in Base.
Standard (which is itself based on Base!) is a smoother usable theme for development purposes, more like the standard that everyone is used to from Moodle 1.x. It's still fairly minimalist. It's going to be a good basis for simpler themes that just want to add a few colours and images.
2. Yes, plugins should take care of their own Base layout in their own styles.css (example for forum)
1. You can use any core theme to base a new one on.
Base is a real bare-bones theme with basic layout only, no colors etc. It's a better basis for creative themes where you plan a lot of changes and don't want to be overriding styles all the time (as people used to have to do in 1.9). It's not really designed to be usable as a theme itself. And yes we should be correcting obvious layout problems in Base.
Standard (which is itself based on Base!) is a smoother usable theme for development purposes, more like the standard that everyone is used to from Moodle 1.x. It's still fairly minimalist. It's going to be a good basis for simpler themes that just want to add a few colours and images.
2. Yes, plugins should take care of their own Base layout in their own styles.css (example for forum)
My feeling is just that Base is a little too basic as it currently is. It should include all styles to ensure that the layout is consistent (for example, tables and forms should be centered, margins should be appropriate, etc.). I realize there is a fine line here, but it's something I will work on, for sure.
I'd ideally like Base to be complete enough that all one has to do is select it as a parent theme, and code the broader parts of Moodle to effect greater change. As is, I'm having to check every single module and am finding a lot of strange presentation that is not set in Base or the module.
Therefore, here's my proposed course of action for my next theme:
1.) I'll start coding on top of the Base theme.
2.) When I encounter something that should just be part of Base (for example, the participants table not being centered at all), I'll add it there instead of my theme.
3.) When I encounter something inside a module that should be part of the module "base" styles, I'll add that to the the module's styles.css file.
Theme developers: It's absolutely crucial that you file bugs and improvements as you find them. My work over the weekend uncovered a lot of things that need fixing/improving. If there is no ticket in the tracker, I can't promise I'll find them. So, as you're working, if you say to yourself, "Hey, there are two .generalbox divs on the same page without any way of distinguishing between them. I'd really like to style this .generalbox and not that one. This div needs a class or id.) Submit it!
Also, note that Boxxie will probably be recoded once I have this second theme complete. Our goal is 20 themes in the core - some of them will have to be created by you, but all of them should be based on "Base" so that I can fix major issues with a single fix to a single theme. If you're developing a theme and you realize that you are frequently adding this one bit of CSS, let me know by filing a ticket so we can discuss the merit/problems with adding it to Base.
There are my general thoughts, rambling though they are. Please developers, let me know your thoughts soon so I can continue working. Thanks!
I'd ideally like Base to be complete enough that all one has to do is select it as a parent theme, and code the broader parts of Moodle to effect greater change. As is, I'm having to check every single module and am finding a lot of strange presentation that is not set in Base or the module.
Therefore, here's my proposed course of action for my next theme:
1.) I'll start coding on top of the Base theme.
2.) When I encounter something that should just be part of Base (for example, the participants table not being centered at all), I'll add it there instead of my theme.
3.) When I encounter something inside a module that should be part of the module "base" styles, I'll add that to the the module's styles.css file.
Theme developers: It's absolutely crucial that you file bugs and improvements as you find them. My work over the weekend uncovered a lot of things that need fixing/improving. If there is no ticket in the tracker, I can't promise I'll find them. So, as you're working, if you say to yourself, "Hey, there are two .generalbox divs on the same page without any way of distinguishing between them. I'd really like to style this .generalbox and not that one. This div needs a class or id.) Submit it!
Also, note that Boxxie will probably be recoded once I have this second theme complete. Our goal is 20 themes in the core - some of them will have to be created by you, but all of them should be based on "Base" so that I can fix major issues with a single fix to a single theme. If you're developing a theme and you realize that you are frequently adding this one bit of CSS, let me know by filing a ticket so we can discuss the merit/problems with adding it to Base.
There are my general thoughts, rambling though they are. Please developers, let me know your thoughts soon so I can continue working. Thanks!
I think it is a judgement call exactly where the boundary between base and standard lies (within the framework that Martin sets out). I think you (Patrick, and other contributors here) are the ones best placed to make that judgement.
I just hope that the appropriate rule of thumb can then be added somewhere in the coding guidelines, for the benefit of developers creating new stuff, so they can to the right thing to make their new code easy to theme.
I have to disagree with "(for example, the participants table not being centered at all)".
Surely, the base theme should not be making an assumption like 'centre everything', which is one of the things that makes theming Moodle 1.9 a real pain (if you want a left-aligned theme).
I just hope that the appropriate rule of thumb can then be added somewhere in the coding guidelines, for the benefit of developers creating new stuff, so they can to the right thing to make their new code easy to theme.
I have to disagree with "(for example, the participants table not being centered at all)".
Surely, the base theme should not be making an assumption like 'centre everything', which is one of the things that makes theming Moodle 1.9 a real pain (if you want a left-aligned theme).
Surely, the base theme should not be making an assumption like 'centre everything', which is one of the things that makes theming Moodle 1.9 a real pain (if you want a left-aligned theme).
The participants table is a large table that should take up at least 85% of the width of the content and have equal space to the left and right of the theme. The current base theme does not set an alignment and does not set a width for this table. Therefore, it has to be set in the new theme.
I can go about this in one of multiple ways:
1.) I can add such common layout styles directly to the Base core.css (or otherwise appropriate) stylesheet.
2.) I can create a new theme (base+) that is based on the Base theme and build ALL of my themes off that (this seems like a strange choice to me but will be necessary considering the amount of coding necessary to get base ready to actually work as a starting point for projects).
3.) I can create new stylesheets for these new layout elements. That way, if a theme developer wants to exclude my centering (or other elements) they can exclude them from the styles.
Interesting note by Tim!!
#3 is the best route when it comes to organization of how I would like it to be. +1 from me for #3 Patrick.
Cheers!!
#3 is the best route when it comes to organization of how I would like it to be. +1 from me for #3 Patrick.
Cheers!!
Patrick you are asking very good and important questions here.
@1.) Please don't add design oriented CSS to Base in any way. (See my other post for the reasons)
@2.) What is strange with this proposal? When everybody might agree that Base is basic and nothing more and all design oriented CSS goes into the individual themes and you plan to create a set of similar themes it seams logical to me that you create a "master" theme with the CSS all other themes have in common. And then create the variations on top of the master. You would create a great example how such a theme "family" can be built and maintained.
And you would not force for example me when I work on a completely different design to overwrite CSS you added for a different context.
Design is mostly created in a certain context and needs to fulfill certain needs. You are in one special situation. Your task is to create nice looking general purpose themes. Your task is to make the themes work in the broadest possible use scenarios. When you add all CSS needed for this broad use scenario to Base designers will need to overwrite a lot of this CSS. This situation we know from 1.9 themes we need to avoid.
@3.) To keep the CSS highly modular would have many benefits. Modular CSS files are easier to understand. You can document the CSS in the context of the module they style. It's easier to combine CSS.
I propose you try to create your "master" and your theme "family" and use modular CSS. I see the most benefit for most of us in such an approach. And I am sure others will create their theme "masters" and "families".
I appreciate your perspective on theme "families" and think this is the route I'll go then. Base will contain only basic styles. I'll create a new theme that uses Base as it's parent.
Base <- Grandparent
New Family <- Parent
New Themes <- Child
Base <- Grandparent
New Family <- Parent
New Themes <- Child
I think Urs and Patrick are reaching the right consensus.
Two further questions:
1. Is what Urs calls "master", and Patrick calls "New Family <- Parent", one and the same as what "standard" is supposed to be? If so, should Patrick call his parent theme "standard"? (Or are there a few things that need to be in the standard theme, but not in "master" - a bit like the things in the old "formalwhite" theme?
2. I believe (but I may be out of touch) that there are two options for where to put the CSS for mod_quiz in the "master" theme. It can go in theme/master/{something}.css (typically modules.css), or it can go in mod/quiz/styles_master.css. Currently, Development:Themes_2.0 says use the first option (the second option is only for people making third-party plugins) However, I am not sure that is the best answer.
Well, the real point of Question 2 is: as a developer of a module, how much CSS do you expect me to write? Certainly I should create mod/quiz/styles.css, so the quiz basically works. But, should I also create mod/quiz/styles_master.css so that my module looks nice in most of the common Moodle Themes? In the past, we were expected to keep the standard theme looking nice, which ensured that most other themes, which were based on standard, looked nice.
Two further questions:
1. Is what Urs calls "master", and Patrick calls "New Family <- Parent", one and the same as what "standard" is supposed to be? If so, should Patrick call his parent theme "standard"? (Or are there a few things that need to be in the standard theme, but not in "master" - a bit like the things in the old "formalwhite" theme?
2. I believe (but I may be out of touch) that there are two options for where to put the CSS for mod_quiz in the "master" theme. It can go in theme/master/{something}.css (typically modules.css), or it can go in mod/quiz/styles_master.css. Currently, Development:Themes_2.0 says use the first option (the second option is only for people making third-party plugins) However, I am not sure that is the best answer.
Well, the real point of Question 2 is: as a developer of a module, how much CSS do you expect me to write? Certainly I should create mod/quiz/styles.css, so the quiz basically works. But, should I also create mod/quiz/styles_master.css so that my module looks nice in most of the common Moodle Themes? In the past, we were expected to keep the standard theme looking nice, which ensured that most other themes, which were based on standard, looked nice.
1.) There are things in the Standard theme that probably won't go into my new structural theme. Then again, there are probably things that will go into my structural theme that aren't in Standard. My point of view is that Standard is there as a historical reference for administrators. I don't necessarily want to alter that too much and I want the freedom to alter this new structural theme however I see fit - I don't plan on it having any particular nice bits.
2.) I'll reserve editing mod stylesheets for serious issues and will proceed with extreme caution. All design CSS will go into the theme CSS.
3.) I imagine that plugin developers should create as much CSS as necessary to ensure the plugin looks the same across all themes. If they choose to style for specific themes for whatever reason, they are free to do so.
2.) I'll reserve editing mod stylesheets for serious issues and will proceed with extreme caution. All design CSS will go into the theme CSS.
3.) I imagine that plugin developers should create as much CSS as necessary to ensure the plugin looks the same across all themes. If they choose to style for specific themes for whatever reason, they are free to do so.
As Martin and Tim already mentioned Base should be what the name suggests - very basic to keep elements at place and care that the page does not fall apart. Base is not the place to hold CSS following design decisions. All this design oriented CSS is candidate to be overwritten by a majority of designers styling Moodle. The need to overwrite leads to unnecessary bloated CSS.
It's very important to keep alignment out of Base. Elements in Base should follow the language selected by the user - LTR languages align left, RTL languages to the right. Selecting center alignment is a design decision made for a certain implementation context and no universal decision. Please, please let's stop the nuisance to force designers to overwrite not fitting alignment. We need to be able to set alignment not to overwrite it.
You write "... but all of them should be based on "Base" so that I can fix major issues with a single fix to a single theme".
With this statement you bring up a very important aspect which needs to be considered carefully.
Easy maintenance.
And we have another very important aspect:
Great flexibility
The culprit is that you can't get both at the same time. Easy maintenance means most possible consistency. Flexibility means most possible variability.
The only possible solution for this contradiction seams to be to work with theme groups or "families" which share "master" themes to keep the families easily maintainable.
People who want no hassle with maintaining themes follow your "family".
People who need to create individual designs and don't want to overwrite a lot of CSS create their own themes and probably theme families.
And one aspect comes into my mind while writing - when you overwrite a lot of CSS you loose the easy maintainability anyhow because you need to correct your own CSS when the underlying CSS is changed. So with many themes it does not really matter if you create them form Base with a lot of "new" CSS or overwrite another theme with a lot of "new" CSS.
And one aspect comes into my mind while writing - when you overwrite a lot of CSS you loose the easy maintainability anyhow because you need to correct your own CSS when the underlying CSS is changed. So with many themes it does not really matter if you create them form Base with a lot of "new" CSS or overwrite another theme with a lot of "new" CSS.
Well said. Families, then.
Hello all,
Just dropping in my thoughts on this discussion which has raised some fantastic questions thank you Patrick.
The following was true in splitting the standard theme from 1.9 into base and standard for Moodle 2.0:
The base theme is intended to be a VERY basic theme, certainly not suitable for use in any regards by itself, and not selectable as a theme unless theme designer mode is on. Things such as alignment, margins, padding, and widths were left out in all cases where there inclusion was not vital to function. It's sole purpose is to provide an instant step up for theme developers looking to greatly customise a theme by ensuring they get some very bare essentials.
The standard theme in contrast of course extends base with all of the niceties to give it that classic 1.9 look
. It's intended to give Moodle a look, it CAN be used when creating a new theme if it's in the same direction as the desired design.
CSS that fixes bugs such as overflow problems, wrapping issues, width+float bugs, or anything else that may cause a functional problem should be included in base.
CSS that does not fix a functional issue should go into the theme.
In splitting the base and standard theme within Moodle 2.0 I removed alot of CSS that was no longer applicable, things such as classes that were no longer used, duplicate selectors and rules (there were HEAPS), and general tiding. I have no doubt that several things were missed and/or left left out.
If you find something that will be critical to all theme's then by all means add it to base. If it's something that is a nicety or design decision add it to the theme you are developing.
Please however if you do add something to base check all other theme's in Moodle and remove any duplicates of the rules you are adding. This helps keep Moodle clean.
In the case of modules the styles.css file that exists within the module's directory should contain the base CSS, any additional CSS for look in regards to a particular theme should be included in that theme.
For the plugin developers out there of course you can't necessarily edit theme's to add your design CSS, this was of course a big problem in Moodle < 2.0... which has now been solved hooray! you can create a styles_themename.css file for each theme you want to add CSS for. That styles_themename.css file will of course build upon what ever CSS you have in your styles.css file.
Extend base if you want to take full control of the look of a theme, extend another theme if you can find a look you like and want to build upon.
If you want a real challenge, or want to take absolute control over Moodle's look then don't extend anything!
Cheers
Sam
P.S Urs thank you for the truly fantastic explanation and ideas on theme organisation and implementation
Just dropping in my thoughts on this discussion which has raised some fantastic questions thank you Patrick.
The following was true in splitting the standard theme from 1.9 into base and standard for Moodle 2.0:
The base theme is intended to be a VERY basic theme, certainly not suitable for use in any regards by itself, and not selectable as a theme unless theme designer mode is on. Things such as alignment, margins, padding, and widths were left out in all cases where there inclusion was not vital to function. It's sole purpose is to provide an instant step up for theme developers looking to greatly customise a theme by ensuring they get some very bare essentials.
The standard theme in contrast of course extends base with all of the niceties to give it that classic 1.9 look
. It's intended to give Moodle a look, it CAN be used when creating a new theme if it's in the same direction as the desired design.CSS that fixes bugs such as overflow problems, wrapping issues, width+float bugs, or anything else that may cause a functional problem should be included in base.
CSS that does not fix a functional issue should go into the theme.
In splitting the base and standard theme within Moodle 2.0 I removed alot of CSS that was no longer applicable, things such as classes that were no longer used, duplicate selectors and rules (there were HEAPS), and general tiding. I have no doubt that several things were missed and/or left left out.
If you find something that will be critical to all theme's then by all means add it to base. If it's something that is a nicety or design decision add it to the theme you are developing.
Please however if you do add something to base check all other theme's in Moodle and remove any duplicates of the rules you are adding. This helps keep Moodle clean.
In the case of modules the styles.css file that exists within the module's directory should contain the base CSS, any additional CSS for look in regards to a particular theme should be included in that theme.
For the plugin developers out there of course you can't necessarily edit theme's to add your design CSS, this was of course a big problem in Moodle < 2.0... which has now been solved hooray! you can create a styles_themename.css file for each theme you want to add CSS for. That styles_themename.css file will of course build upon what ever CSS you have in your styles.css file.
Extend base if you want to take full control of the look of a theme, extend another theme if you can find a look you like and want to build upon.
If you want a real challenge, or want to take absolute control over Moodle's look then don't extend anything!
Cheers
Sam
P.S Urs thank you for the truly fantastic explanation and ideas on theme organisation and implementation
Thanks Sam. This conversation has been a big help, for sure.
Sam,
Can you check that the changes I've made to the Moodle Doc Creating Your First Theme are correct, mainly to do with pagelayout, since I believe you wrote the original?
Many thanks
Mary
Can you check that the changes I've made to the Moodle Doc Creating Your First Theme are correct, mainly to do with pagelayout, since I believe you wrote the original?
Many thanks
Mary