Hello Theme Designers,
We've got a tracker ticket in progress to do with the YUI CSS Resets. It would be great if we could get input from the community. Have you dealt with the resets? Overridden them? How often and in what context?
https://tracker.moodle.org/browse/MDL-36198
Can I ask what you mean by resets as I am beginning to suspect we may be at cross purposes here.
My understanding of CSS Resets which I learnt from Eric Mayer, from whom I quote...:
"...The goal of a reset stylesheet is to reduce browser inconsistencies in things like default line heights, margins and font sizes of headings, and so on..."
This is why we need to make html. body {margin: 0; padding: 0;} because some browsers add 10px padding others a 10px margin. If you don't add the reset your page looks different in the different browsers.
This is why I suggested that BASE theme might as well carry the reset, after all it's pretty minimal, since BASE theme should in fact style all of Moodle elements nicely, and look nice it self (which is does not with all the black lines round ever generalbox. That is NOT a reset that's just YUI CSS putting a line round things it think need lines. The problem with Moodle is that everything is in a box, be it general or otherwise.
So yes we do override YUICSS but the actual reset is something different and should be treated as such.
You cannot do away with the reset as it is needed, but what we could do with less of is the total YUI CSS that seems to pervade all of Moodle especially when there is a lot of CSS in Base theme that overrides it.
I'm beginning to favour the Object Oriented CSS method which, if done correctly, could halve the CSS in Moodle. Then we could do away with YUI CSS alltogether!
Cheers
Mary
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.
I'm with David at every point here. We can add normalize to themes as theme designers. One of the difficulties with the YUI resets is that theme designers are locked in to them; they don't get to choose. And with Moodle moving to the html5 doctype normalize really will be better.
David has the option of deleting those files from his installation, but for a partner like Remote-Learner, with many, many installations to manage, we need to have installations be standardized, and any change requires a new repository to track that client's code base, along with the labor to manage that repository.
What that would mean, though, is that if core themes need/want to use normalize.css or another reset, then that reset should be added to that theme, and not to base. So that is something to think about. Otherwise some folks would still be overriding resets but from base instead.
David has the option of deleting those files from his installation, but for a partner like Remote-Learner, with many, many installations to manage, we need to have installations be standardized, and any change requires a new repository to track that client's code base, along with the labor to manage that repository.
What that would mean, though, is that if core themes need/want to use normalize.css or another reset, then that reset should be added to that theme, and not to base. So that is something to think about. Otherwise some folks would still be overriding resets but from base instead.
If we disable RESET what happens to the browser html.css (Firefox)
I don't think either David or I are recommending disabling or disallowing resets; we're recommending placing resets within the theme, rather than locking theme designers into YUI resets that are deprecated and do not address new HTML5 elements.
That way theme designers can go with the reset that they prefer, or find is best for the site's end-users.
That way theme designers can go with the reset that they prefer, or find is best for the site's end-users.
What about having it within core, but able to be toggled by the theme? The theme config could have a couple of new settings added:
$THEME->yuireset = true; // Includes YUI reset CSS by default, so themes can opt out
$THEME->normalize = false; // Doesn't include normalize.css by default, but themes can opt in
The values above would seem like sensible defaults, so that existing themes don't get broken by the change - but theme designers working on new (or updating existing) themes could then opt to do what they wanted. Alternatively, a unified $THEME->resets = ['yui','normalize']; could be added to allow for other options (either now or in the future) without needing to add more settings.
Sounds like a good idea, Paul. This could be implemented now and utilised in future themes. You should suggest this as an improvement to MDL-36198.
Cheers
Mary
That was Petr's recommendation at the start. But what happens when normalize is forked, or theme designers want to add a new reset that is not YUI or normalize? How many resets will we add PHP settings for (and ship in Moodle, and keep up to date for years and years)? Why not let theme designers update and maintain their own resets?
The issue with breaking existing themes won't happen if we adopt this in concert with theme versioning.
The issue with breaking existing themes won't happen if we adopt this in concert with theme versioning.
If there's a reasonable degree of consensus that Normalize is a good option, we could start with just that and the current YUI reset/base. That way, themes can choose to remain untouched (i.e. continue using the YUI reset/base), switch to Normalize or turn off both. If you (as a theme designer) wanted to use something that isn't provided (whether it be a newer/specific version of Normalize, or something completely different), you could turn off the built-in resets entirely and use whatever you want.
Personally, I favour providing at least one or two options in core, because that way we don't end up with a different version of the same reset in each theme - and updating/maintaining goes both ways: if Moodle core provides Normalize (for instance), theme designers don't need to keep up to date with Normalize and release a new version of their theme each time there's a new Normalize release; it can instead be updated once, in Moodle core, and all themes which use it benefit from the update.
This is the same reasoning I used when I said it would be better to add a reset.css in Base theme as it too can be easily excluded from a theme, if that theme uses Base as a parent theme.
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.
I know, right? Wouldn't it be great to halve the CSS? And have fewer things break when you need to add overrides? :D
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.
Moodle 2 themes where created and added in 2010 thats not that long ago.
Lots of the core styles may be old and depreciated by now or inneed of a face lift, but the theme CSS is relatively new, but does need tidying up.
I'm fairly certain that there's corners of Moodle 2 that were carried over untouched from Moodle 1.9 and whose roots go back further. Since there's little gain from going back and pruning the CSS it tends to grow unconstrained, that's why starting from scratch and then only bringing across what you need makes sense.