David Scotson

In some themes you can alter the Bootstrap variables, and then generate new .css from the .less. One of those variables controls the roundness of the corners, so if that's the kind of theme you are dealing with then a few variable changes should get rid of most rounded corners in one go.

In defaul Bootstrap those options are:

@baseBorderRadius: 4px;
@borderRadiusLarge: 6px;
@borderRadiusSmall: 3px;

And setting them all to 0 should get rid of rounded corners. I don't know if this is possible with the theme you currently use, but it's something we do to achieve pointy corners in a Bootstrap 3-based theme, so possibly worth looking into. A similar technique could probably remove most borders as well.

Hi Rosa,

the grunt-uncss strategy doesn't work well with Moodle. It requires knowing in advance exactly what HTML will be used in advance. This is easy to figure out if you've created a 1, 2 or 3 page static site with Bootstrap, you can just look at the pages and see what's been used, then dump the CSS that doesn't match.

Moodle on the other hand can have user entered content in forums, quizzes etc. and can show different HTML depending on different circumstances (e.g. a bit of HTML may only show up when a student is overdue for an assignment).

There has been an effort over time to reduce the amount and variety of HTML used to produce visually similar things (e.g. .smallicon vs .iconsmall) and adopt standard Bootstrap classes across core and 3rd partly plugins but it's been slow going.

What might have a similar impact in the short term however, is taking advantage of Moodle's modularity, and turning off anything that you don't use/need. Every block, and every module etc. supplies it's own styles.css file that is bundled together. If you don't intend to use that block or module, then you know that the CSS in that file is wasted. Spending some time switching off things, particularly if you have a site with a very specific focus that e.g. only needs forums and assignment but not quiz, lesson, chat or whatever, should have a noticeable impact on the size of the resulting CSS.

Are you using Chrome as a browser?

You may be affected by this bug MDL-50795 "Copying and Pasting within or between Atto boxes adds background color definition in Chrome".

The current resolution of the bug is just to remove the background color part, but the bug also discusses lots of other bits of style that get added. If that is the same thing you may wish to ensure that they open a follow-on bug to discuss what to do about the rest of the styles that get cut'n'pasted into Atto.

Most pages have unique class or id on the body tag that you can use to target them, e.g. this page that you're currently looking at is body#page-mod-forum-post, login page is body#page-login-index, front page is body#page-site-index.

Course pages are annoying because different course formats have different ids, like body#page-course-view-topics and body#page-course-view-weeks, so you can list all that apply.

I've often wondered whether it makes sense to just force all the profile images to the f1 size.

In the Snap theme we want to emphasis the user images, and once you've got the large user image cached from viewing the forum, it perhaps doesn't make sense to then load a small copy when looking at another page. You trade off loading the larger image by default, with not having to load two different ones.

(A recent-ish change to use jpg for user images made this decision easier, as it reduced the file size of the larger user images)