If you're doing any serious work with Moodle CSS I would genuinely recommend that you at least try to delete all the current CSS and start again from scratch. Large amounts of it are repetitive, redundant, or counter-productive since it's been built up over many years and still has the scars of long-forgotten battles with IE6. The tricky part is identifying the useful bits and restoring them, but I'd guess those bits are way under half, maybe 20%?, or even less if you eliminate redundancy across modules.
David Scotson
Posts made by David Scotson
One reason for not doing this is that it places some "special" CSS files outside of the normal workflow.
At the moment, on this very page you get one giant (5000 lines) CSS file which gathers together lots of individual files and makes them faster to load and easier to cache. You also get 4 tiny files (average ~30 lines each) for these special YUI CSS files. It would be better if that was just one file.
For the same reason you've got a whole bunch of people complaining about the disappearing table borders in MDL-27774 but of the two bits of CSS that need fixed, only one is in the theme so it makes it much harder to fix.
There was a similar issue with images some of which live in core moodle and some e.g. for the drag'n'drop file upload live in the base theme. Generally moving things into the theme increases flexibility and removes some of the "magic" of guessing where things are coming from. At the moment we have a confusing distinction between what is "core" Moodle and what is part of the Base theme.
At the moment, on this very page you get one giant (5000 lines) CSS file which gathers together lots of individual files and makes them faster to load and easier to cache. You also get 4 tiny files (average ~30 lines each) for these special YUI CSS files. It would be better if that was just one file.
For the same reason you've got a whole bunch of people complaining about the disappearing table borders in MDL-27774 but of the two bits of CSS that need fixed, only one is in the theme so it makes it much harder to fix.
There was a similar issue with images some of which live in core moodle and some e.g. for the drag'n'drop file upload live in the base theme. Generally moving things into the theme increases flexibility and removes some of the "magic" of guessing where things are coming from. At the moment we have a confusing distinction between what is "core" Moodle and what is part of the Base theme.
Moodle includes (at least) two YUI files, reset.css and base.css
Reset takes away all the styles so that everything is consistent (but odd looking), then Base (the YUI css file of that name, not the Moodle Base theme) adds them back again including a few extra odd ones like putting black borders round every table cell (which is a totally bizarre thing to do! I was genuinely shocked that they did that).
Both can be replaced with normalise.css (which Bootstrap and various other modern frameworks build on top of).
It's shorter, simpler & better. They talk on their site about the difference between traditional resets and their normalize solution:
http://nicolasgallagher.com/about-normalize-css/
Basically instead of tearing it all down and building it back up, which is effective but somewhat brutal, they just tweak as necessary to achieve the same end result. This takes more detailed research beforehand to figure out exactly what needs tweaked where, but means less work for the browser when the person is actually loading the webpage. The actual file itself is fairly readable:
https://github.com/necolas/normalize.css/blob/master/normalize.css
I think these can just be a part of the themes though, not part of Moodle.
Reset takes away all the styles so that everything is consistent (but odd looking), then Base (the YUI css file of that name, not the Moodle Base theme) adds them back again including a few extra odd ones like putting black borders round every table cell (which is a totally bizarre thing to do! I was genuinely shocked that they did that).
Both can be replaced with normalise.css (which Bootstrap and various other modern frameworks build on top of).
It's shorter, simpler & better. They talk on their site about the difference between traditional resets and their normalize solution:
http://nicolasgallagher.com/about-normalize-css/
Basically instead of tearing it all down and building it back up, which is effective but somewhat brutal, they just tweak as necessary to achieve the same end result. This takes more detailed research beforehand to figure out exactly what needs tweaked where, but means less work for the browser when the person is actually loading the webpage. The actual file itself is fairly readable:
https://github.com/necolas/normalize.css/blob/master/normalize.css
I think these can just be a part of the themes though, not part of Moodle.
It looks like this is the key line that disables it:
lib/csslib.php
39=function css_store_css(theme_config $theme, $csspath, array $cssfiles) {
43: if (!empty($CFG->enablecssoptimiser) && $theme->supportscssoptimisation) {
https://github.com/moodle/moodle/blob/master/lib/csslib.php#L43
The theme_config class in lib/outputlib sets this setting to "true" by default
lib/outputlib.php
113=class theme_config {
335: public $supportscssoptimisation = true;
https://github.com/moodle/moodle/blob/master/lib/outputlib.php#L335
I've not located the actual change in bug MDL-32628 yet (the github links seem dead) but is that the reason I have ?rev=8 on the ends of profile picture links?
Shouldn't that respect the slasharguments and not use a "?", Google recommends against them for things you want cached as some proxies assume it's not going to be a static resource.
Shouldn't that respect the slasharguments and not use a "?", Google recommends against them for things you want cached as some proxies assume it's not going to be a static resource.