The Moodle CSS separation solution is quite up to date
That articles' comments certainly make for an interesting read. I think there are many there who would disagree that the "separation solution is quite up to date" ;)
I don't mind the idea of separate stylesheets personally, it's how things are separated that can make the difference between a pain in the bum and a well-ordered structure. This presentation raises some interesting points: http://natbat.net/2008/Sep/28/css-systems/
I don't mind the idea of separate stylesheets personally, it's how things are separated that can make the difference between a pain in the bum and a well-ordered structure. This presentation raises some interesting points: http://natbat.net/2008/Sep/28/css-systems/
As always how you design your CSS suits your need.
Separated style sheets in Moodle are brilliant when you want to start using Parent themes. To bring in just the layout and font info while leaving color behind ensures that none of this info is brought into the new theme by mistake. Of course of this was all done in one CSS file I would need to ensure I had overrides in place for every colored area to make sure I got it all.
However, if you are building a theme for your site, to be used just by you and you know wont need the separated functionality, then you can always build your own CSS in one file.
The separated nature just gives developers the ability to bring in specific CSS info of their choosing and I personally think it is great that we can do so.
Julian
Separated style sheets in Moodle are brilliant when you want to start using Parent themes. To bring in just the layout and font info while leaving color behind ensures that none of this info is brought into the new theme by mistake. Of course of this was all done in one CSS file I would need to ensure I had overrides in place for every colored area to make sure I got it all.
However, if you are building a theme for your site, to be used just by you and you know wont need the separated functionality, then you can always build your own CSS in one file.
The separated nature just gives developers the ability to bring in specific CSS info of their choosing and I personally think it is great that we can do so.
Julian
It's certainly a wonderful goal to separate form from presentation. This has been a boon to visual designer for the internet. However, I agree with some of the comments to the ALA article. Separating your CSS into "font", "layout", and "color" just adds to the complexity of working with the document. It sounds good as a theory but it actually makes the Moodle CSS harder to work with.
It creates unnecessary complexity to have to search through three different documents to find all of the ways that a specific class or id is affected. This is further complicated when considering the cascade of CSS, where CSS can be over-ridden by greater specificity and order that it occurs in the document.
I would rather have that one class or id tag in the CSS document and then all of the CSS that affects it. These class and id tags can be grouped into sections with comments in the CSS document, grouping them by functionality and where they generally occur in the rendered html document. You can also then use that order to help make clear some of the dependancies where certain style over-ride others by grouping them together. As far as I can tell, with limited PHP understanding, the config.php file basically compiles the three CSS files into one file anyway.
i.e. header, body, footer, HTML (overwrites of HTML tags), active styles (a:hover), Moodle modules, Moodle blocks, book content
- - -
Julian's comment about parent themes has me confused. If you have a master theme and you wanted to create a dependent theme that did not change any colours but changed layout, you would not have to write over-rides for color.
/*parent theme*/
.column-header {width: 20%; background-color: #ccc;}
/*child theme*/
.column-header {width: 30%;}
...and the parent background-color would be passed to the child. Did I misunderstand you?
- - -
In the Moodle documents they mentioned CSS zen garden. I think that is a misleading reference for Moodle Themes. I don't feel that CSS is a skin put on top of the HTML like they do on that website. Moodle is an application and the CSS affects the user interface of that application.
An analogy is that Zen Garden was an HTML mannequin and it was easy to change its outfits. Moodle is a two year old child that keeps moving, growing new arms and legs, and upgrading in size and complexity, and bending in unexpected ways. That's not a problem, but it's a totally different way of thinking about how you design your CSS.
Just like a programer who hacks Moodle's core PHP coding and has a complicated crashing mess when a new version of Moodle comes out. So to someone who rewrites Moodle's CSS at a very specific level will have problems with upgrades and often have problems in how an unforeseen aspects of Moodle interacts with the change. In many ways it's safer to avoid changing how the base Moodle CSS works. It can be quite hard to problem solve strange interactions.
Scale of your Moodle implementation is also a factor. I work for an organization with 1200+ employees and I'll tell you that I've seen people use and do things in Moodle that I would have never imagined or considered. It's often impossible to expect people to do things in a certain way that will not break Moodle (i.e. sticking in a really really long URL that doesn't line-break).
I expect it is too late to change the course of Moodle's CSS in how it is organized. But I think there are things that can be done to help make it more usable for designers to work into.
best wishes,
Ian
It creates unnecessary complexity to have to search through three different documents to find all of the ways that a specific class or id is affected. This is further complicated when considering the cascade of CSS, where CSS can be over-ridden by greater specificity and order that it occurs in the document.
I would rather have that one class or id tag in the CSS document and then all of the CSS that affects it. These class and id tags can be grouped into sections with comments in the CSS document, grouping them by functionality and where they generally occur in the rendered html document. You can also then use that order to help make clear some of the dependancies where certain style over-ride others by grouping them together. As far as I can tell, with limited PHP understanding, the config.php file basically compiles the three CSS files into one file anyway.
i.e. header, body, footer, HTML (overwrites of HTML tags), active styles (a:hover), Moodle modules, Moodle blocks, book content
- - -
Julian's comment about parent themes has me confused. If you have a master theme and you wanted to create a dependent theme that did not change any colours but changed layout, you would not have to write over-rides for color.
/*parent theme*/
.column-header {width: 20%; background-color: #ccc;}
/*child theme*/
.column-header {width: 30%;}
...and the parent background-color would be passed to the child. Did I misunderstand you?
- - -
In the Moodle documents they mentioned CSS zen garden. I think that is a misleading reference for Moodle Themes. I don't feel that CSS is a skin put on top of the HTML like they do on that website. Moodle is an application and the CSS affects the user interface of that application.
An analogy is that Zen Garden was an HTML mannequin and it was easy to change its outfits. Moodle is a two year old child that keeps moving, growing new arms and legs, and upgrading in size and complexity, and bending in unexpected ways. That's not a problem, but it's a totally different way of thinking about how you design your CSS.
Just like a programer who hacks Moodle's core PHP coding and has a complicated crashing mess when a new version of Moodle comes out. So to someone who rewrites Moodle's CSS at a very specific level will have problems with upgrades and often have problems in how an unforeseen aspects of Moodle interacts with the change. In many ways it's safer to avoid changing how the base Moodle CSS works. It can be quite hard to problem solve strange interactions.
Scale of your Moodle implementation is also a factor. I work for an organization with 1200+ employees and I'll tell you that I've seen people use and do things in Moodle that I would have never imagined or considered. It's often impossible to expect people to do things in a certain way that will not break Moodle (i.e. sticking in a really really long URL that doesn't line-break).
I expect it is too late to change the course of Moodle's CSS in how it is organized. But I think there are things that can be done to help make it more usable for designers to work into.
best wishes,
Ian
I searched the forum to see what others have said on this topic. I am also seeing the proposition that having one single CSS makes it harder to make a custom theme based upon a standard Moodle theme like "standardwhite".
Couldn't you just add a file called styles_custom.css and put it in the config.php so that it occurs below the other files when compiled and, hence, has greater specificity and over-rides the master theme?
i.e.
$THEME->standardsheets = array('styles_layout','styles_fonts','styles_color','styles_custom');
I'm all for basing themes on the standard themes Moodle provides. Our developers here have been explaining how down-stream (us) and up-stream (moodle.org) relate, and there is no use fighting what's happening upstream!
Couldn't you just add a file called styles_custom.css and put it in the config.php so that it occurs below the other files when compiled and, hence, has greater specificity and over-rides the master theme?
i.e.
$THEME->standardsheets = array('styles_layout','styles_fonts','styles_color','styles_custom');
I'm all for basing themes on the standard themes Moodle provides. Our developers here have been explaining how down-stream (us) and up-stream (moodle.org) relate, and there is no use fighting what's happening upstream!
Hi there, theme guru's. I have just integrated uploadify (a multiple file uploader) into one of my modules. Uploadify however, requires special css in order to display it's upload progress bar correctly. How can I include the css into moodle without having to edit the style_layout.css or other standard moodle css files?
I want to distribute my module without having to require the user to edit their css.
any ideas?
Thanks in advance!
I want to distribute my module without having to require the user to edit their css.
any ideas?
Thanks in advance!
2 options,
1. Edit config.php
$THEME->standardsheets = array('styles_layout','styles_fonts','styles_color','YOURCSSFILEHERE');
2. Include it in header.html
<link rel="stylesheet" href="<?php echo $CFG->themewww .'/'. current_theme() ?>/YOURCSSFILEHERE.CSS" type="text/css" media="screen">
The choice is yours!
1. Edit config.php
$THEME->standardsheets = array('styles_layout','styles_fonts','styles_color','YOURCSSFILEHERE');
2. Include it in header.html
<link rel="stylesheet" href="<?php echo $CFG->themewww .'/'. current_theme() ?>/YOURCSSFILEHERE.CSS" type="text/css" media="screen">
The choice is yours!
Ian > Separating your CSS into "font", "layout", and "color" just adds to the complexity of working with the document. It sounds good as a theory but it actually makes the Moodle CSS harder to work with. It creates unnecessary complexity to have to search through three different documents etc.
I totally agree with you, Ian. I fail to see the advantage of separating the CSS into 3 files. When I create or edit some CSS rules for one moodle element, I want to be able to change font or layout or color in the same place, not have to look into 3 separate files!
Joseph
PS.- "It sounds good as a theory..." gives me the opportunity to quote (again
) a favorite of mine:
"Theory is when we know everything but nothing works. Practice is when everything works but no one knows why. We have combined theory and practice: nothing works and no one knows why!" Alan Maley ‘Classroom practice: an overview’, in R. Bowers and C. Brumfit (eds.) Applied Linguistics and English Language Teaching. MacMillan, London, 1991.
I totally agree with both of you!
After struggling for some time solving http://moodle.org/mod/forum/discuss.php?d=123250 I think Moodle's CSS file structure really could and should be simplified.
Another disadvantage:
As Moodle compiles all those CSS files before sending the CSS to your browser when working with Firebug the line numbers it gives you are useless for actually finding the relevant CSS in your Moodle file(s).
If you want to use separate CSS files you should separate them by semantic criteria (e.g. core, modules, activities...) not by presentational aspects (color, font, layout...). Chances are that you want to change all presentational aspects for a certain module (the chat module for example). You should only have to sift through one file in that case, not at least three as it is now.
Is there already an issue in the tracker so one can vote for it?
Cheers,
Frank
PS:
Great quote! We should give them a place in Moodle Docs to live in
After struggling for some time solving http://moodle.org/mod/forum/discuss.php?d=123250 I think Moodle's CSS file structure really could and should be simplified.
Another disadvantage:
As Moodle compiles all those CSS files before sending the CSS to your browser when working with Firebug the line numbers it gives you are useless for actually finding the relevant CSS in your Moodle file(s).
If you want to use separate CSS files you should separate them by semantic criteria (e.g. core, modules, activities...) not by presentational aspects (color, font, layout...). Chances are that you want to change all presentational aspects for a certain module (the chat module for example). You should only have to sift through one file in that case, not at least three as it is now.
Is there already an issue in the tracker so one can vote for it?
Cheers,
Frank
PS:
Great quote! We should give them a place in Moodle Docs to live in