Upgrade-friendly way of adjusting font sizes globally

[ohadschn]

It seems the recommended way of adjusting font sizes is overriding _reset.scss. However that file is pretty big and any override risks missing out on potential theme upgrades.

I was thinking maybe extract the relevant lines to their own CSS, or somehow expose the font sizes as variables (without overriding all of _variables.scss for similar reasons)?

Related: #167, #1184.

[mmistakes]

The way Jekyll handles _sass files you have to actually override the entire folder for it to accept any of your changes. So even if you override _reset.scss it won't take. And as you pointed out that's a large file and probably something you don't want to mess with if possible.

There's actually a simpler solution. Because of the way CSS works, you can add all of your custom overrides or "new" CSS to a single file, assets/css/main.scss.

This file has 2 lines, and the chances of it changing are slim to none since all it does is import another Sass partial that contains all of the theme's components and modules.

So what you can do is add any overriding/new CSS after the @import minimal-mistakes;, in your case:

@import "minimal-mistakes";

html {
  font-size: 16px; // change to whatever

  @include breakpoint($medium) {
    font-size: 18px; // change to whatever
  }

  @include breakpoint($large) {
    font-size: 20px; // change to whatever
  }

  @include breakpoint($x-large) {
    font-size: 22px; // change to whatever
  }
}

These will cascade and override the font-sizes declared earlier in the CSS.

[tensaurus]

works 👍

[TobiasSchaffner]

This is an alternative I came up with to only adjust the size of the posts and leave everything else the same:

@charset "utf-8";

@import "minimal-mistakes/skins/{{ site.minimal_mistakes_skin | default: 'default' }}";
@import "minimal-mistakes";

.page__content {
  p,
  li,
  dl {
    font-size: 0.75em;
  }
}

[kbroch-rivosinc]

@TobiasSchaffner : I like your suggestion, the only problem I found is I am using the right nav bar toc and using page__content was shrinking the text there as well. I instead choose the class sectionbody and got the result I was looking for.

[ohadschn]

Great stuff. BTW what is the difference between this and type-size-X?

[mmistakes]

Setting a font-size in pixels on the base html element is a common way of laying the foundation for responsive typography. Google around and you'll find some articles/blog posts that explain it better than I could.

The type-size-x variables are just em based sizes that act as multipliers of the base font sizes set in pixels.

For example when the screen size is less than $medium you have a base size of 16px. If you set an element with $type-size-4 or 1.25em it's essentially doing 16 x 1.25 to give you 20px size. @medium and where the base size jumps to 18px you'll get 18 x 1.25 or 22.5px, @large 20px you'll get 20 x 1.25 or 25px, and so on and so fourth.

[ohadschn]

Ah, I see. So if one wants to make everything smaller categorically across the entire site, indeed it makes sense to alter the base pixel size as above, rather than change all the multipliers...

[mmistakes]

You got it.

[MV10]

@mmistakes Should this work on a Github Pages site using remote_theme?

There's actually a simpler solution. Because of the way CSS works, you can add all of your custom overrides or "new" CSS to a single file, assets/css/main.scss.

Based on the structure page in your docs, I created an /assets/css/ directory in my repo and put the modified main.scss there, but nothing changes after pushing.

[mmistakes]

@MV10 yes this should work. Your issue might be how styles are cascading and specificity depending on what you're trying to do . What does the content of your /assets/css/main.scss look like?

If you override any variables found in _sass/_variables.scss by placing them in your main.scss without the !default they will override.

And if you're adding CSS to main.scss it needs to appear after the imports so it overrides anything in the bundled CSS. That's how the "cascade" in CSS works, what comes last overrides what came before it.

[MV10]

Exactly as you demonstrated earlier but with different px sizes.

--- 
# Only the main Sass file needs front matter (the dashes are enough) 
--- 

@charset "utf-8";

@import "minimal-mistakes/skins/{{ site.minimal_mistakes_skin | default: 'default' }}"; // skin
@import "minimal-mistakes"; // main partials

// https://github.com/mmistakes/minimal-mistakes/issues/1219#issuecomment-326809412
html {
    font-size: 12px; // originally 16px
    @include breakpoint($medium) {
        font-size: 14px; // originally 18px
    }

    @include breakpoint($large) {
        font-size: 16px; // originally 20px
    }

    @include breakpoint($x-large) {
        font-size: 18px; // originally 22px
    }
}

[mmistakes]

@MV10 I just tested this locally and it worked perfectly for me. The font sizes reduced in size.

Looks to me like you have a caching issue. Is this happening locally or on GitHub Pages? You'll need to clear your browser cache and likely wait for GH to pickup the change and flush whatever cache of the site assets it has as well.

No idea if there is a way to force that on their end or not.

[MV10]

You're probably right, I didn't think about the CSS being cached. I'm currently jacking up my DNS settings (lol) so I'll circle back to this a bit later. Thanks for the help.

[MV10]

Edit: Apparently I have to publish a page change -- then it updates. Success! Thanks again for the help.

[MV10]

Some quick follow-up, it still isn't working. (And just to be clear, there isn't any caching going on -- I can add a main.CSS, not scss, and it shows up instantly.)

I know at this point it's probably nothing in your theme -- I've been talking to GitHub support about this the past few days. But I thought I'd share the weirdness, I suppose. To simplify matters, for testing purposes, the only CSS tag at the end of main.scss is a body background color setting, so it's very obvious when it does work.

Bottom line, the file seems to fail with anything in there except regular CSS. When I remove the charset and both imports, it will process. If I add just charset back, it fails. If I add just the imports back, it fails. Even just adding a // comment line to the file causes it to fail. I tried commenting out the skin entry (I'm using neon) and re-testing just charset, then just the imports, and even each individual import (which is nonsense, but I was trying everything), and it fails, so at least the skin files aren't somehow at fault. I even tried both types of comments (inline and block) and they cause failures both ways.

Nothing works except plain CSS in the file by itself. I suppose I should clarify all tests had empty front matter.

It's all pretty strange -- especially since it did process exactly one time, seemingly at random, but never again. It even failed later on when I set up the file the same way that worked that single time.

Hopefully GitHub support can tell us something useful. It sucks that they don't dump build logs somewhere that we can see.

[mmistakes]

What's the repo with these changes made that you're not seeing reflected on GH Pages?

I'd like to clone it and see if I can reproduce and/or see what's being missed. Because I tried this exact thing from a base MM install locally using the GitHub Pages gem, and it worked perfectly.

Can you verify that you've setup your Gemfile for use with gem "github-pages", and tried building things locally? That would help eliminate some caching issues with GH Pages as building locally in this manner takes it out of the equation.

[MV10]

Bah, apparently one of the parsers chokes on the UTF-8 Byte Order Marks that Visual Studio insists on slipping into the file when it saves. First time in probably ten years that I've heard of anything not being able to handle the BOM. Oh well. Problem solved.

[ohadschn]

@MV10 try running a batch file (bat) with a BOM in CMD...
That BOM inserted by VS is pretty annoying.

[MV10]

Ha, I doubt I've run a batch file in 10 years... Powershell! :)

[elzbth]

Hi all, I'm trying to add /assets/css/main.scss to my project and every time I run bundle exec jekyll serve it is deleted. Is there a different command to use?

[mmistakes]

@elzbth Make sure you're adding it to the root of your project and not in the _site folder. That is recreated every time Jekyll runs.

[SalmonMode]

I just ended up here after doing some digging. The solution mentioned here works for me, but only if I put the two lines of triple dashes in the beginning of it. This lines up with what's mentioned in the Jekyll docs here.

Jekyll provides built-in support for Sass and can work with CoffeeScript via a Ruby gem. In order to use them, you must first create a file with the proper extension name (one of .sass, .scss, or .coffee) and start the file with two lines of triple dashes

[raja-ashok]

Currently the font size of post in homepage (summary of all latest post with title and initial paragraph) is in appropriate size. But the actual post (post title and body) font size looks much bigger.

Even with this solution post font size can be reduced. But this in turn makes home page fonts size much smaller that is unacceptable.

I am looking for solution to keep same font size on home page as well as in post (for both title and body font size) ?

Modifying theme's scss file like this solution also not correct I feel.

[mmistakes]

@raja-ashok This is an intentional design decision. Excerpt text is smaller than post/page body text. You’ll need to modify the theme’s CSS if you want something different.

[ElectricRCAircraftGuy]

Worked for me! Here's what I used to get a much more natural look.

In assets/css/main.scss:

---
# Only the main Sass file needs front matter (the dashes are enough)
---

@charset "utf-8";

@import "minimal-mistakes/skins/{{ site.minimal_mistakes_skin | default: 'default' }}"; // skin
@import "minimal-mistakes"; // main partials


/*
GS: override any CSS with new CSS styles AFTER the `@import "minimal-mistakes";` line just above!
See: https://github.com/mmistakes/minimal-mistakes/issues/1219#issuecomment-326809412
Anything you place after this point will therefore "cascade and override" the previous CSS styles.
*/

/*
GS: Decrease font sizes of the entire website.
Defaults for small, medium, large, and x-large screens are:
16, 18, 20, and 22px, in that order. All other font sizes are "em"
[typography unit](https://en.wikipedia.org/wiki/Em_(typography)) multipliers of these pixel
(px) values, and are therefore relative to and changed by these singular pixel values.
See: https://github.com/mmistakes/minimal-mistakes/issues/1219#issuecomment-326809412
- It looks like the screen pixel sizes to move into each new "size" category are defined in
  the "Breakpoints" section of "_variables.scss"?
*/
html {
  font-size: 12px; // change to whatever

  @include breakpoint($small) {
    font-size: 12px; // change to whatever
  }

  @include breakpoint($medium) {
    font-size: 14px; // change to whatever
  }

  @include breakpoint($large) {
    font-size: 16px; // change to whatever
  }

  @include breakpoint($x-large) {
    font-size: 18px; // change to whatever
  }
}