I've been looking at Moodle's CSS a lot recently, and if I had to point to one core issue with the current CSS, I'd say that's there simply too much of it.

This has two key impacts: complexity for developers, and size for browsers.

There's simply too much CSS in Moodle for any one person to understand. What is there contains repetition, near-duplication, unused code as well as simple bugs and typos. It's not well laid out or formatted, it's often over specific which makes it hard to override in themes. Mostly it's like looking at the CSS of a collection of vaguely related websites rather than one web app. This makes it very hard to work on, which encourages people to avoid what's there and just do their own thing, creating a vicious circle which leads to mounting technical debt as well as simple bulk.

That bulk then leads to issues on the receiving end. Every line needs to be compressed and sent across the internet, possibly over slow mobile networks and then stored in browser memory and each line scanned for each item on the page (again possibly on low powered phones).

For end users of Moodle these issues translate into Moodle being uglier, slower, harder to use and buggier than it needs to be.

I don't think there's any one easy solution to this, but there's plenty of smaller things that together would add up to a noticeable difference. So here's a list of things that could be done in the 2.6 dev cycle to reduce the amount of CSS in Moodle. Note that often, in order to reduce CSS you need to fix the HTML that it applies to as well.

It's just a list in no particular order, when/if work begins then sub-tasks that can be prioritised would probably make more sense:

1. Locate and remove CSS that no longer has corresponding HTML. There's lines in core CSS aimed at IE5 for example. (There's tools to automate locating unused CSS like this they'd possibly need tweaked for a dynamic application like Moodle)

2. Reformat the CSS so that it's readable. Currently it's half compacted and difficult to read and edit, possibly a holdover from the days before we had a CSS compressor built in.

3. Reformat the CSS so that it's more compressible. Well formatted CSS that does the same thing in the same manner is easier for gzip to compress. There's tools that will help with this.

3. Include a new, better CSS minifier. Currently we have two, one that doesn't do very much and an experimental one that sometimes breaks things. The key feature of the latter is (I believe) that it removes duplicated CSS. We should avoid having duplicate CSS in the first place. There's 3rd party code that tackles this tricky problem well and is already used across the web. (edit: note I found out later that this isn't actually necessary. Moodle already includes a good quality, 3rd party minifier, just in a slightly odd way that made it non-obvious to find. That and the fact that a new homegrown one was being written, confused me into believing they didn't already have a very good one included in the codebase.)

4. Standardise the component HTML of Moodle. There may be as many as 20 different styles used to layout forms in Moodle, I lost count at some point after 10. These should all use the same styles as far as possible.

5. Minimise admin styles. Moodle doesn't have an admin/user split like some other web apps. This means all admin styles get sent to every user (and all user styles get sent to every admin). A specific effort should be made to minimise the variation of the admin interface to reduce this load.

6. Use a CSS grid. This saves having to specify floats repeatedly.

7. Debug code shouldn't have any unique CSS styles. Debug styles get sent to every user, but probably get seen on 1 in a million page views or less. If it can't be done with CSS that's already in the theme, then in extreme cases inline styles are appropriate for this use case. A simple first step would be to move all the debug code into a single file that can be excluded from the theme if necessary.

8. Add variables to CSS preprocessor so themes can override parts of the core theme by supplying new variables (colors, font faces & sizes) rather than repeating the CSS.

9. Officially deprecate IE7. Currently 2.5 doesn't support IE8, but that doesn't mean it intends to be totally broken, just that bugs aren't such a high priority. IE7 needs a bunch of workarounds for inline-block etc. We should removed these and drop actively drop support for it. (Bootstrap 3 only supports IE8)

10. Upgrade to Bootstrap 3. This version is more focussed and streamlined which should lead to smaller CSS.

11. Fix the two main causes of extra CSS for the Bootstrap theme: make a renderer for buttons, mark standard simple tables with a .table class. Then continue with the next largest wins.

12. Fix bugs. There's lots of little issues that, mostly as a side-effect, have an impact on the amount of CSS output. These should be tagged in the bug tracker to allow their impact on CSS to be considered in their level of priority.

13. Break the styles into smaller files with related content. This helps you find existing styles that fit together, and any needless duplication.

14. Find a better way to do RTL. Some of this is just an extension of the above. If you have a rule for ie5 then you might also have an RTL rule for ie5, which doubles the impact. But also, there should be a system so that RTL CSS doesn't include LTR CSS and vice-versa. Currently we just tag the RTL stuff onto the end of the LTR stuff, which can lead to 3x as much CSS. (First the LTR code, then something to reset that, then the actual RTL code). One simple fix would be to enforce a layout for RTL add a simple preprocessor to strip it out when not needed.