- Notifications
You must be signed in to change notification settings - Fork408
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
| @font-face { | ||
| @font-face { | ||
| font-family:"Fira Sans"; | ||
| font-display:swap; |
There was a problem hiding this comment.
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 ofauto for which some user agents may block longer?
Generally I'm biased towardsauto for stuff like this but I thinkswap is reasonable and doesn't critically override user preference, unless their browser usesfallback for crappy internet connections or something like that. But the font files are really small so I wouldn't be that worried about it.
krunchington left a comment
There was a problem hiding this 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 commentedMar 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 commentedMar 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 somevisual differences (e.g. we used a variable weight of 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 wecompare Firava (variable version) with the Fira-latin subset we're using in 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. <linkrel="stylesheet"href="/site.css" /><linkrel="stylesheet"href="/fonts-{{language}}.css" /> |
cart commentedMar 15, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
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. |


Uh oh!
There was an error while loading.Please reload this page.
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: