Skip to content

Replace Fira font with variable version #1945

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

doup
Copy link
Contributor

@doup doup commented Mar 13, 2025

Replaces Fira font with a variable version. With two files (regular & italic) we get the whole range of weights 100-900. I was expecting that this would also reduce the file size weight but it's slightly bigger. The big advantage of switching is that increases the range of weights available, which I would like to use to improve the typography of the content pages (docs, news…).

Font taken from: https://github.com/hellogreg/firava (OFL license)

Differences:

  • File size:
    • Variable (regular+italic): 128kb
    • Non-variable: 108kb
  • Kerning is different, but I don't know which one is better
  • The weight is not the same at any given point (e.g. 700). Also, in some cases there might differences because we were using unsupported weights (e.g. 800 when we only had a 700 font).

font-family: "Fira Sans";
font-display: swap;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume this is intentional in order to show the text as quickly as possible, over the default of auto for which some user agents may block longer?

Generally I'm biased towards auto for stuff like this but I think swap is reasonable and doesn't critically override user preference, unless their browser uses fallback for crappy internet connections or something like that. But the font files are really small so I wouldn't be that worried about it.

Copy link
Contributor

@krunchington krunchington left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't verified the font assets but the css changes all look right to me.

@cart
Copy link
Member

cart commented Mar 14, 2025

Looks like we drop from 1700 characters to 450 characters. Are we sure the added flexibility is worth it, especially in light of the increased size?

@doup
Copy link
Contributor Author

doup commented Mar 14, 2025

After challenging a little bit the idea… I would say that the main reason for not doing this is that if the webpage is translated to Chinese and there isn't a variable font for Chinese, then there might some visual differences (e.g. we used a variable weight of 250 for the English text but the Chinese font only support 200 or 300). It's probably easier to keep cross-language visual consistency if font-weights are limited.

I don't think that the file size (Firava can be subsetted to reduce file size) or not supporting other alphabets are issues, see below.


If we compare Firava (variable version) with the Fira-latin subset we're using in main then Firava actually comes with more characters. Although the extra languages that Firava supports still use latin alphabets. The size difference probably comes from this, if we generate a smaller subset of Firava to support the same languages as in main I expect that the file size will be lower than main.

main:
image

Firava:
image


If we need to support languages using other alphabets (e.g. Chinese), instead of adding more characters to the font files we're already loading, we could split the CSS by language. So we load the specific font files and CSS rules for that language. This allows to cohexist latin/non-latin, variable/non-variable… without bloating the user with stuff that they don't need.

<link rel="stylesheet" href="/site.css" />
<link rel="stylesheet" href="/fonts-{{language}}.css" />

@cart
Copy link
Member

cart commented Mar 15, 2025

Ah right I forgot we switched to the subset. In light of that this seem like an acceptable move (provided we're happy with how the font behaves in practice). Can you capture some images to compare (with a common anchor position so flipping between them is easy / useful). I'd also like this to include a pass over font weights in code to ensure we "snap" any existing weights to their previous "fixed" weights. Seems like there could be cases where a weight of 600 was specified, which got rounded down to 500. Switching to a variable weight would mean we are slightly bumping up the weight without intention.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants