Cleaning up our font system

It’s possible, but I think we’d lose some flexibility because viewport units are only relative to the viewport and not each other. If someone wanted to scale-up/down individual components they’d have to change every value within that component (or redefine all the variables used within). I was running into a similar limitation using REMs.

One thing we could do though, is change our html {font-size: 14px;} at different breakpoints, which would scale all the type in the app.

Got a github repo for what you have so far yet?

So far I’ve gone as far as making sure most of the font-sizes are in ems and shifting values to the scale I outlined above (except for font-awesome icons, which need to exist outside the system). That’s in this typography-2.0 branch:

https://github.com/discourse/discourse/tree/typography-2.0

I also have the scale in codepen if you want to try it out a bit:

5 Likes

By the way:
There is an small issue with the font size at the categories view. The font size of the subcategories are different from the categories on right column / topic list. It‘s pretty strange and new …

4 Likes

I‘ve noticed, that the font size is changing when I hold my iPad (mini 4) in portrait and landscape mode. In portrait mode, the size of the topic listing overview is (I guess) 1-2 times smaller, which makes it more difficult to read.

1 Like

Similarly to font-size we also have a large variety of line-height definitions, these are a mix of px, em, and unitless values.

It’s important to fix line-height here as well, because otherwise we’ll still have problems scaling font-size. For example, If you want to update a 14px (1em) font-size to 16px, and there’s a 14px line-height set, you now have a line-height that’s too small for your font-size.

That’s why it’s recommended that unitless line-height values are used, because your line-height will always be based on the font-size. With 14px font-size and line-height of 1, your line height will be 14px. Update the font-size to 16px and your line-height will be 16px. Unitless line-heights serve as multipliers of the font-size, not values.

11 Likes

New font system is live

This new font-size and line-height system has been merged into Discourse. These variables exist in our variables.scss file, and if you’re contributing to core you should refer to these (font-awesome icons are an exception).

If you’re nesting font-sizes, you can move up/down the scale using addition/subtraction. For example: If you have a parent div set to font-size: $font-up-6; and you set font-size: $font-down-2; within it, you’ll end up at font-size: $font-up-4 (so based on the root font size, that’s 1.7511em).

We also have 3 variables for line-heights now. These should generally be used to space lines of text, and not to create additional padding/margin on elements like buttons (we were using line-heights in some weird ways). Since these are unitless values, they’ll scale along with font size changes.

$font-up-6: 2.296em;
$font-up-5: 2em;
$font-up-4: 1.7511em;
$font-up-3: 1.5157em;
$font-up-2: 1.3195em;
$font-up-1: 1.1487em; 
$font-0: 1em; 
$font-down-1: .8706em; 
$font-down-2: .7579em; // Smallest size we use based on the 1em base
$font-down-3: .6599em;
$font-down-4: .5745em;
$font-down-5: .5em;
$font-down-6: .4355em;

$line-height-small: 1;
$line-height-medium: 1.2; // Headings or large text
$line-height-large: 1.4; // Normal or small text

Scaling fonts in themes

As a proof of concept, I created a “large fonts” theme available in the hamburger menu here on Meta. This theme consists of a single line of CSS: html {font-size: 16px !important;} (our default is 14px). You’ll see some small issues with margins in the header/nav (which should be easy to overcome in a full theme with a few additional lines of CSS), but overall scaling fonts should now be significantly easier.

You can also target individual sections of the UI and all the child elements will scale proportionately. For example, if you wanted to only scale the font size for posts, you could set .topic-post {font-size: 16px;}.

22 Likes

Looking good (not noticed anything glaringly different, which I guess is the point)

5 Likes

3 posts were merged into an existing topic: More formatting bugs with font size refactor

First of all, great to see some work being done on the fonts :+1:

I have an old theme with a gazillion font rules and fixes that I would gladly move to the new system. However, I noticed the new font system results in fractional font sizes and line heights. This brings back some bad memories from issues with font rendering on low dpi displays and sub pixel rendering. Is this intentional? Any way to (easily) stick to full pixel values? The variables cant be overridden from themes either, right?

What specific issues are you talking about, screenshots please.

1 Like

Of what, memories? I would like to increase the font size on my theme and use full pixel values unlike the default, is that not possible with the new system?

I hate proposing solutions if I can not visually see what problem it is your are trying to solve.

Screenshot please of big problems with DPI issue related to partial px values or it did not (or no longer does) happen on modern browsers :woozy_face:

6 Likes

There’s no easy way to change this unfortunately, you’d have to figure out a way to replace our SASS variables before they’re compiled (maybe a plugin could do it? I don’t think anyone has attempted it before).

We’ve been doing it this way for a full year now and haven’t had any issues with fractional values reported. Happy to fix any issues you may encounter due to it.

5 Likes

Hi, is this possible to change (override) these font system variables?

$font-up-6: 2.296em;
$font-up-5: 2em;
$font-up-4: 1.7511em;
$font-up-3: 1.5157em;
$font-up-2: 1.3195em;
$font-up-1: 1.1487em;
$font-0: 1em;
$font-down-1: .8706em;
$font-down-2: .7579em;
$font-down-3: .6599em;
$font-down-4: .5745em;
$font-down-5: .5em;
$font-down-6: .4355em;

I am adding this variables with custom values to CSS section, but there is no change?

It is not possible to override these, they’re already compiled in Discourse’s default CSS. You’d have to override the individual styles manually with your own values.

3 Likes

If you’re okay with the relative changes in the font sizes, you can simply set a different font size on the :root element, and the ems will scale to match.

3 Likes

Am I missing something, or is this just a case of not wanting to give a footgun to theme/plugins? Declaring all of these variables with !default seems like an easy way to allow for overriding these.

2 Likes

I don’t believe it worked before because core styles were compiled before a theme could override them? It was that way for colors anyway… I know some things about how we compile SCSS changed so maybe that’s not an issue anymore?

We can also switch these to CSS custom properties like we did with colors if !default isn’t enough.

3 Likes

Derp that’s right. It sounds like custom properties are the right way to go after all! :muscle:

4 Likes

Here’s a refactor for your review, this one may work better to allow any stylesheet to use or update the vars:

https://github.com/discourse/discourse/pull/12746

OK I’ve wrapped my head around it a little more – Currently, all the variables defined here are able to be read from themes/plugins, but not write new values, as each stylesheet is compiled separately. Adding css custom properties allows themes/plugins to override the variables dynamically, and all dependent stylesheets pick up the new values. :slight_smile:

3 Likes

hey @bekircem with the above merged, you can now add a theme that overrides the base font variables by way of re-defining the (client side) css properties now:

// probably don't use these values, but you can get the idea here:
:root {
    --font-down-1: 0.8em;
    --font-0: 2em;
    --font-up-1: 3em;
    --font-up-2: 4em;
}
3 Likes