StackOverflow selected the following font stack [1] after holding an open discussion [2]. Note that their initial proposal included system-ui which they later removed due to concerns about OS and language compatibility.
@ff-sans:
-apple-system, BlinkMacSystemFont, // San Francisco on macOS and iOS
"Segoe UI", // Windows
"Liberation Sans", // Linux
sans-serif; // The final fallback for rendering in sans-serif.
@ff-serif: Georgia, Cambria, "Times New Roman", Times, serif;
@ff-mono:
ui-monospace, // San Francisco Mono on macOS and iOS
"Cascadia Mono", "Segoe UI Mono", // Newer Windows monospace fonts that are optionally installed. Most likely to be rendered in Consolas
"Liberation Mono", // Linux
Menlo, Monaco, Consolas, // A few sensible system font choices
monospace; // The final fallback for rendering in monospace.
That's their preferential font stack, not a system font stack.
It's mostly Helvetica based: San Francisco is the Apple knock off of Helvetica and Liberation Sans is a knock off of Arial which is a knock off of Helvetica. Only Segoe UI isn't Helvetica.
I'm pretty sure the font choosing algorithm takes into account the "lang" attribute as well. lang attribute and the system language are probably used to determine the fallback order. For example, on Windows 10+ with system font stack without system-ui: [0], [1]
For Han characters:
- lang="en" + system lang en -> "Chinese" font
- lang="en" + system lang ja -> "Japanese" font
- lang="ja" + system lang en -> "Japanese" font
For Hiragana, Katakana:
- lang="en" + system lang en -> "Japanese" font
which is reasonable enough but can be surprising I think. This can be confusing when you care enough about how the Han unified characters look but can't control the lang attribute (for example in Discord messages).
Side note, if the system lang is en and on Windows 10+, Japanese Github markdown text will be shown in two fonts with different "weights" [3]. It looks fine if your system lang is Japanese. I wonder if it's possible to set/guess a custom lang attribute for user/repo/markdown document.
It’s really unfortunate that the response to this blog post was to gum up CSS forever instead of fixing the browsers to do reasonable things with `system-ui`.
This is done in order to mitigate Han Unification - I suspect on OSs that aren't ancient this is probably Fine, but if you have a huge userbase like Bootstrap you probably need to support these people
I wish browsers chose better default fonts which would make monospace, sans-serif, and serif more appealing. As an alternative, adopting new CSS keywords like user-monospace, user-sans-serif, user-serif could allow web developers to prioritize user-configured fonts in the browser.
Because whatever is default depends on too many variables.
Like if you're on a Japanese OS but your language preferences are English, the default sans-serif font is a Japanese typeface that often doesn't display Roman alphabets that nicely.
Because I feel like the former is meant to have Japanese fonts even for Latin glyphs for consistency's sake, but I understand that some people do prefer the other way.
And indeed, MacOS system font by default is like that. Windows is the opposite, though (everything is in Meiryo UI or whatever it's now called.) (Not sure if it's changed in Win11 either.)
Not the OP, but I'm sure it's webpages that don't have the lang attribute at all, which is why macOS used the Japanese font stack instead of the English one.
On Windows at least (can't test MacOS at the moment), the default `lang` of web page when there is no attribute is actually the display language of my browser (in both my and OP's case, English), not my OS's (Japanese).
Furthermore, Firefox has a heuristic lang detection algorithm (!) based on content. I wrote an article about it 10 years ago, but not sure if it has been changed.
> the default `lang` of web page when there is no attribute is actually the display language of my browser (in both my and OP's case, English)
Uhh, let me check...
> MacOS Monterey, default system language is Japanese but obviously I browse a lot of English websites.
I don't think that OP ever stated that their browser is in English, just saying that they also browse English sites (and they're probably not using Firefox - its text rendering is super consistent across different systems). Safari (obviously) and Chrome (less obviously) in macOS defers to the OS for text rendering - hence the problem.
For backwards compatibility, most likely. If sans-serif on a particular platform has been FontX for 25 years browser vendors probably don’t want to suddenly change it for all existing websites.
That's not how I see it. I see it as not trusting that the default is good looking so we'll list a bunch of good-looking fonts with the hope that we get a hit and the browser doesn't use an ugly default.
If the user wants their styles to take precedence, that’s what UA override stylesheets are for. Defaults are not overrides. Defaults are fallbacks, for sites that don’t care.
A nice article, but I do wish there was something similar for the increasingly less Edge Case of VR/AR/XR as a category because the font stacks in 3D perform different. There are chromium forks like the Meta Oculus Browser and Igalia has taken over Firefox Reality Browser now called Wolvic and embedded Unity browsers like Vuplex all running in a specific vendor's Android build. I find a lot of non-generic CSS/Font combos break in WebXR experiences without even getting into CJK or RTL issues. Then you have the game engine side of font handling which is a different topic but gets in the way of compatible rendering behavior.
The worst ones are in emails from the likes of Microsoft where they have segoe and nothing else listed so half their messages look like a random default serif font (they don't even have fallback sans listed).
I'm kind of confused as to why they don't have a demo showing all the fonts. I'm not just going to blindly pick from system fonts, I want to choose which I prefer first. Yeah I could look them all up, but just seems like they missed showing off the core thing...
That’s not the point. This is supposed to be a stack that gets you the system font on Windows, Android, Apple platforms, and maybe Ubuntu. It looks the same way the rest of the OS does, unless the user did something weird (eg. install Avenir on Windows).
I'm guessing license issues would be a problem. Roboto wouldn't be an issue, but I'm pretty sure Microsoft's and Apple's default font files require a license to host.
Oddly enough, the page doesn’t use the font stack it proposes. They moved Segoe UI to the end of the list, before Arial, so Windows users who installed Roboto will see Roboto instead.
Yep, on my Windows 11 machine these fonts are rendering as Arial, which is most definitely _not_ the System UI font. I would definitely consider an alternative to this stack.
I'm actually dealing with the massive font differences that break the designs, and I don't know how to solve it. The designer specced the fonts that are available on different OSes. Something like font-family: X, Y, sans-serif;.
The problem is, X and Y have different line heights and different widths. And there's no CSS / media query way to detect which font is available.
So far I'm leaning towards a very ugly solution: rendering a test string into a DIV, measuring it, and then applying the correct class to the parent element.
At some point, you just have to give up and understand that a pixel perfect representation of a design is not possible. We're not working in print anymore.
I thought something like this would been obvious after 2 decades of transitioning from print to web design, but I sometimes still get complaints for things like widows and orphans [0].
Personally, I think orphans are bad typography and have little to do with pixel perfection. I don’t see why responsive web design necessarily requires bad typography.
Given the tools to address these issues, such as Adobes proposed `text-wrap: balance`, I am sure many would do so.
Stop trying to enforce pixel perfect control. This is equivalent to old school Win32, VB6 GUIs with hardcoded pixel positioning of all controls designed to work on a 640x480 screen. Web technologies are designed to accommodate flexible layout. Accepting font rendering differences is part of that.
It’s not as petty as you make it sound. You don’t have to pixel peep to spot the differences. Switching to a different font can break basic stuff like text in a button being vertically centered, which can look broken or amateurish to normal site visitors.
You can still have this problem apply even if you are using flex and aligning items to the center.
If a font has some weird characteristic about it (for instance, the font itself has built in whitespace at the bottom or top of letters), you will not be able to center it vertically no matter what CSS magic you try to do except for doing some kind of translation on it; that translation doesn't have to be pixel-based either, but it will 100% have to happen until hopefully when the leading-trim property that
saadat mentioned is widely available.
this only looks terrible because you've forced a specific height in rem. https://jsfiddle.net/vbd3fok5/ looks fine to me. there is some extra space, but I assume that if the font designer added extra space on top of the text, they did it on purpose. if you insist on ignoring that, https://jsfiddle.net/qpb0d45n/ makes the text "visually continuous", at least for a non-Korean reader like myself. I would speculate that a Korean user might look at this and ask why the site designer ignored their font's preference for space above the text.
It's not even about being pixel perfect. I can't vertically align text with an image. If I align it with one font, the other one is misaligned. I need something like media query for fonts.
I don't see how flexbox solves this problem. Just because you vertically center text, doesn't mean that the visible text is actually centered. It depends on the font.
The CSS property leading-trim [1][2] is designed to solve this alignment problem (among others). However, it's still at the Working Draft stage, so it's going to take a while before browsers start supporting it.
In the past I found slight width differences between Windows and Mac that made a text take up a second line. Also, Google Fonts sometimes are updated and this can cause letter widths to change.
… My recommendation is not to implement any design that can’t handle the difference. This will be more robust and better for you in the future (e.g. i18n, zoomed fonts for a11y, etc.). Whenever I worked implementing a design by someone else and there were overly strict assumptions about text size I let them know this was a problem and suggested an alternative.
The problem with your proposed solution is that if you’re using a webfont and measure before it loads, it won’t match the width once it’s replaced. Also, back in the day browsers came with a command to increase char size instead of zooming the whole page… I no don’t know if some still do, or if it happens under certain contexts (a11y extensions?) but that would also break.
You can not solve that problem. You can not even guarantee font size, it's useless to worry about a font's width. Part of your job as a web developer is to make your employer understand the realities of the web platform.
> I'm not going to tell my employer I'm not implementing the design, when I can solve the problem, though in an ugly way.
Though you might make the site pixel-perfect on _your_ device with _your_ fonts (all the combinatorics you can think of to test), you are likely breaking something for a screen reader, or user with 200% zoom, or a braille user, or a user with hardcoded fonts for disability reasons, or a user using a Windows phone browser, or a user on IE 8, or a user viewing the site through a corporate proxy that blocks some requests, or a user with CSS styles disabled, or a user who hasn't updated his Mac in six years, or a miriad of other cases.
When you're reimplementing basing browser functionality, you're breaking your site for a lot of users.
> I'm not going to tell my employer I'm not implementing the design, when I can solve the problem, though in an ugly way.
Sometimes graphic designers don't understand all the implications of their design choices in a dynamic medium. It is my job, as an experienced professional, to steer them away from the problems and do the best to capture their intention.
Almost every time designers (who many times were my employers) understood the issue when pointed out and agreed with my solution. Their designs normally only consider the "ideal" cases (e.g. every title / item description fits nicely) because they have to make it look good for the client, but they know reality requires compromise.
Web dev for many years chiming in: please step awayyyyy from the ugly solution. As another reply stated, you cannot guarantee pixel-perfect decision without sacrificing other aspects. It’s not something you should strive for at all in {current year}.
If you want to align the text vertically with an image, use flexbox. If the specific font they want to use doesn’t look right in that context, have them either (1) deal with it or (2) pick another font.
You may be able to override metrics of different fonts with CSS, using ascent-override and descent-override and the local() function to target a font on the system.
Just use a webfont. This is main reason people still buy webfont licenses for Arial (not cheap). They need consistency.
It´s admirable to try to have look of a native platform but nobody thinks this way about websites. Plus only very small % of people would even realize difference between those sans serifs if they werent looking for it side by side.
You should use values like rem, em and ch as they're related to font sizes. If your root font size is 16px then 1rem equals 16 px, you can set the line height to 1.5rem etc. With ch you can limit how many characters an element should fit.
I disagree with much of these stacks. I would scrap at least Avenir Next, Avenir, Helvetica Neue, Helvetica, Ubuntu, Roboto, Noto, Arial, Apple Garamond, Times New Roman, Droid Serif, Times, Source Serif Pro, Apple Color Emoji, Segoe UI Emoji, Segoe UI Symbol, Monaco, Liberation Mono and Lucida Console, and probably a couple more, for one of three reasons: that the family is superfluous, for an obsolete platform, or inferior.
—⁂—
But as a consumer of the web, I personally don’t actually need to worry about these things any more, because I have my browser set to use my chosen sans-serif, serif and monospace faces (Equity, Concourse, Triplicate), and you can too! ① Use Firefox. Other browsers may have something similar; dunno; but Firefox is good anyway. ② Settings (about:preferences) → Fonts → Advanced → untick “Allow pages to choose their own fonts, instead of your selections above”.
I started doing this a few months back as a week-long experiment, and found it so significantly improved the web that I’m not going back. (It did feel a little strange for a few days, as Concourse is a somewhat narrower sans-serif than the likes of Arial, but that’s about the specific fonts that I chose. Now it’s just perfectly natural.)
I have experienced a very few icon-font related breakages, about which I wrote yesterday at https://news.ycombinator.com/item?id=31540234, but it’s surprisingly few given how popular the technique was for a few years. I also get a fair bit of bonus unintended serif from people that have neglected to add a generic font family fallback, or misspelled it (e.g. sans or "sans-serif" (quoted) instead of sans-serif), so that it falls back to the global default, which I have left as a serif.
> ① Use Firefox. Other browsers may have something similar; dunno; but Firefox is good anyway. ② Settings (about:preferences) → Fonts → Advanced → untick “Allow pages to choose their own fonts, instead of your selections above”.
I've been doing this for several years now and I love that Firefox can do this and Chromium can't. However, as you've mentioned, icons break on several websites including DuckDuckGo and rust mdbook (the search icon is replaced as "fl"). In addition, several websites assume that their monospace web font will always load and when it doesn't, code blocks are displayed in sans-serif fonts which is a huge turn off.
I guess both of these issues happen because people assume everyone's using Chromium web browsers?
Nah, it’s nothing to do with Chromium. These things can break in any environment, and you can deliberately break these things in any browser, even if Chromium may not have first-class support for the concept; in uBlock Origin, for example, the rule “no-remote-fonts: * true” (or the filter “$font”) kills web fonts, and, well, I guess you can uninstall all your local fonts or something.
Icon fonts are pretty much an obsolete technique: they were the pragmatic choice for a few years when SVG support was insufficient (most notably for old versions of IE), but they were known* to have accessibility problems, and so now that SVG support is adequate, the icon font technique should be replaced in all cases.
For font-family declarations lacking an appropriate generic fallback family, that’s simple developer error because they don’t know how things are supposed to be done, and that all other families are unreliable—it’s not just people that deliberately disable them like us, but also that not all systems will have a font of a given name, and that web fonts may fail to load because networks are unreliable.
So in both cases, it's just poor web design. This is disappointing.
I could maybe forgive the use icon fonts (Google websites end up breaking the most, android's documentation website for example) but it's unforgivable to write `pre code { font-family: my-random-webfont }`.
Something I can add since I started blocking remote fonts completely in uBlock Origin a couple of days ago: I’ve been noticing lots of broken icon fonts now where I hadn’t before; my working hypothesis is that under the flag we’ve been talking about, Firefox excepts Private Use Area code points and happily loads web fonts for those specific cases. Thus, the cases we’ve been observing of broken icon fonts are where the fonts didn’t use the PUA, whether they tried to choose decent fallbacks (like DuckDuckGo), or used the ligation technique (Material Icons), or just did something weird for no obvious reason.
userContent.css is frightfully inconvenient, since you have to restart the browser for it to take effect. I recommend (and use) the extension Stylus instead, which uses an inferior technique (the injected styles aren’t prioritised correctly as user styles), but can be tweaked more easily and as you go.
I usually test my preferences with Stylus, and once I found a combination I'm comfortable with, it gets perpetuated in the userContent.css for the technical reason you mentioned.
Please don't use this. -apple-system & BlinkMacSystemFont are OK but after that it's just a scattershot list of guesses that will often be wrong. I have most of the fonts in this stack installed on my Linux desktop for various reasons and none of them are the system font. Just fall back to sans-serif for now and adopt future -apple-system equivalents as they become available.
> but after that it's just a scattershot list of guesses that will often be wrong.
What do you mean? If it's wrong, the font ain't there. If the font is there, it's the correct font (according to the desire of the one who made the stack). If my stack has "Liberation Sans", it means that if your system has Liberation Sans, then it's going to be used. And it's very often better than the default system font ("Deja Vu Sans", for example, is a typical fallback on Linux and sucks big times compared to Liberation Sans and compared to many other sans-serif fonts).
The way I see it that's the entire point of these "scattershot list of guesses": you can put several, it absolutely doesn't matter. The goal is to find one that matches before falling back to the default.
People can manually install these fonts for whatever reason (I have some for my Photoshop use) while don't want them as the "system font" (because they're not for their OS).
This is not about literally displaying the system font, but about displaying a reasonably appealing font that is already installed. I could not possibly care less about whatever questionable system choice for sans serif some random Linux user makes.
It looks like a minor difference, but the former one has segoe ui before helvetica (which is hard-coded as Arial alias on Windows), so it would use segoe ui on Windows; while the latter (currently using) one would show the content as Arial on Windows.
There was a time when Helvetica crapped out spectacularly in Windows with a certain combination of user-installed fonts. Can't remember exactly which combination it was or perhaps still is, but anyway that was a pretty solid reason for prioritizing Windows default fonts over Helvetica. Maybe someone pointed that out to the author who changed the content but didn't really test it on their own site.
Back in my day, if you had Helvetica installed on Windows, it wasn’t made for screen rendering and looked terrible. I remember putting Windows-friendly fonts higher in the stack for that reason
IIRC, most Helvetica fonts on Windows computers were installed by Adobe applications, which might explain why the fonts were designed for print instead of screen rendering.
Hard disagree. In most cases, just use the bases like sans-serif, serif, monospace, fantasy. If I'm not getting a tailored webfont appropriate for the site or a heavily curated font stack, I want the font for values I already specifically set in my browser.
How is Times New Roman, Baskerville, Garamond, and Droid Sans all in the same serif stack? These hardly look alike. Arial and Ubuntu look nothing alike. If it's not in the same lineage don't include it, go with the default.
`system-ui` can be useful on modern browsers and I'm looking forward to more browsers adding support for the `ui-*` variants: https://caniuse.com/extended-system-fonts
> No, this is bad because it provides additional signal for fingerprinting.
Not really. The fonts selected by these font-family values should, at most, be dependent on the OS and language of the host system -- which are already easy to detect.
That is easily changed via settings and I hope that browser developers will "freeze" it in future so that it always reports Windows 10 (which was promised to be the final version of Windows).
System font stacks are great what I’d like more are similar “magic” values to system-ui that provide reasonably metrics-matched local fonts. The biggest reason I use system font stacks is not as much to look native as it is to try to have similar text metrics across platforms without the overhead and quirks brought by webfonts.
The system font does bring some advantages though, like on macOS/iOS where that font is San Francisco, it’s designed specifically to look good and read well on screen. Under WebKit you even get hand-tweaked letterforms, metrics, and kerning for different combos of size, weight, and context (title, subtitle, body, etc).
Something that would be really cool is if all browsers did what Apple is doing with San Francisco by shipping with a FOSS screen-oriented font like Inter UI[0].
Why not just let the browser use what its developers feel are most appropriate for serif, sans serif, and monospaced fonts, and avoid specifying specific fonts at all? We’re talking about web pages, not a magazine.
This is exactly my thought. Why make every website specify `system-ui` to look nice? Why not just make it the default? I'm struggling why we need system-ui, ui-serif, ui-sans-serif... When we already have initial, serif, sans-serif...
Whever font discussions come up on Hacker News, asking a question like that is risky, because a lot of people will (at least profess to) not only sincerely answer "yes" but be very, very insistent that web designers should not be able to even suggest the typeface that their pages use. When you press them on this point, at least a small subset of them will go on to explain why all design is bad and image support was probably a mistake.
Giving so-called designers a bunch of tools to make every web page behave differently and taking the design choices away from browser and platform vendors absolutely was a mistake and you can see it really clearly when you look at application design in the mid-1980s to mid-1990s versus the mid-1990s to now “designers get to do whatever they want” era of suck.
* I cannot, in good conscience, say that image support was a mistake. There is too much valuable work that cannot be expressed well in text and needs to be graphical. Ditto sound and video.
* Once you’ve added images, you need rich text. If it’s not there, people who insist on doing it anyway will fake it using pictures of text, which is simpler than proper rich text support, but also a lot worse because it doesn’t work with TTS, cannot be indexed for search, and doesn’t work with the clipboard.
The “pictures of text” problem is not just professional designers justifying their paychecks. They’re all over the place on Twitter and Facebook, because of the poor text formatting options they provide.
I don’t think image, video, or audio support was a mistake. I think CSS and JavaScript and cookies and referers were.
The web had rich text even before it had images, in the form of emphasis and strong emphasis, as well as a variety of other forms of semantic markup to indicate document structure and relationships.
What I’m saying is that if a web page doesn’t work on NCSA Mosaic from 1994—modulo modern crypto and character sets—it is doing something very wrong.
I don’t care that this represents a large proportion of the web today, that doesn’t make it any less wrong.
When you say that, what I hear is: "When tools offer greater flexibility, some people will use them in bad ways. Therefore, no one should have access to those tools."
There are plenty of tools for getting exact matched to a design, PDF for example. That’s not what the web is for and every attempt to cram it into that role has just made it worse.
Just because you can pound nails with a screwdriver doesn’t mean we should just start catering to people who want to do that. Or people who want to use knives as screwdrivers. Etc.
“Branding” and “designer preferences” are bullshit that was specifically rejected by the design of the web in favor of information architecture and interoperability. Leave that shit in PDFs where it belongs and don’t bring it to web pages or native applications.
IDEA:
Browser vendors (or browser engines) should just agree on a bare minimum of modern fonts (the most used perhaps by websites?) and include them with their releases. Additionally, why not have a working group to deal with font upgrades for browsers as we have for CSS, JS (ECMA) standards and so on? And funded by the same billion dollar companies that build browsers...
REALITY:
The engineers who would eventually build all this just laugh and don't care. And HN will talk about this again next year.
While using local fonts is generally a good idea, this provides a reliable signal for fingerprinting.
Therefore I would prefer that every major browser (Safari, Chrome and Firefox) ships its own reasonably chosen set of fonts and doesn't access system fonts (however the user may grant access to system fonts if they are fine with fingerprinting).
This could also simplify web design because now there will be a somewhat standartized set of fonts.
Good to know it, but this is not enough. Browsers should not provide access to local fonts by default because it allows to identify an OS. Therefore, the only sane solution seems to bundle necessary fonts with a browser.
Of course, browser should use its own font rendering library instead of using a system one.
Of course, for browsers that target a single platform (like Safari which is available only on MacOs) this is not an issue, but Chrome or Firefox might be used on many platforms, like Windows 8, Windows 10, Windows 11, Debian, Ubuntu, FreeBSD, Plan 9, Chrome OS and so on.
Chrome's Local Font Access API allows web content to enumerate the names and meta data of local fonts, but doesn't block web content from guessing local font names (e.g. for fingerprinting). The use case is web apps like Figma that want to allow designers to use specific local fonts (such as custom or licensed fonts) in design documents.
That's the right solution. But it won't work for other browsers because unlike Safari, Chrome of Firefox might be used on tens of different OSes and there is no need for marketing companies to know what OS are you using.
Firefox has about:config prefs to block web content from using fonts other than their OS's default system fonts.
The pref names and their possible values:
# Visibility level of font families available to CSS font-matching:
# 1 - only base system fonts
# 2 - also fonts from optional language packs
# 3 - also user-installed fonts
layout.css.font-visibility.standard
layout.css.font-visibility.trackingprotection
layout.css.font-visibility.resistFingerprinting
Thank you for the link. I actually was wondering if there is a list of about:config properties and it seems that most of them are described in that YAML file.
I understand the benefits of font masking but the side effect is too bitter to swallow. Especially, the "chosen set of fonts," which mostly comprises outdated web safe fonts designed for the pixelated era, doesn't seem "reasonable" to my eyes; I simply can't bear looking at Arial, for one. The only workaround I've found is to sideload a CSS (hidden in developer preferences) containing a series of @font-face rules that hijack references to Arial to an online location hosted by myself. But obviously that's inelegant, taxing on performance, and unavailable on iOS.
I use a single font file and it is 230kb. I don't use heavy images anywhere on my website. I think I'd prefer to offer a consistent look across devices and OS than use inconsistent system fonts that all vary in size, spacing, and aesthetic.
That’s not true. Emojis are Unicode characters just like `a` or `ß`. When I type <an emoji character> on my computer it doesn’t magically change font in the middle of the sentence; it’s just a character.
Emojis are Unicode characters, and some emojis appear in all sorts of fonts, but the more fancy emojis, as well as the color renditions of emojis, appear only in the system color emoji font. The font is changed in the middle of the sentence, as part of font fallback.
On my system I've manually updated the Noto Emoji font to get emoji 14 support because I'm not updating to Ubuntu 22.04 on my daily driver to get the new font support.
Emoji are often rendered using the system's font fallback mechanism. When one font doesn't have the glyph required, another font that does have the glyph gets picked. Most fonts don't have glyphs for non-western scripts; there are only a few fonts out there that cover most of the Unicode standard, often made up of several fonts combined.
You're not manually changing the font-face mid sentence, but when you use emoji the renderer is definitely switching fonts to one you didn't specify.
> it doesn’t magically change font in the middle of the sentence
It's not magic but it can happen. In fact, it usually does. Helvetica doesn't have emoji glyphs. Guess what happens if you drop an emoji in a block of text formatted with Helvetica?
It's great to see that "Liberation Mono" is added (it's a great font family available on some Linux systems, some of which may not have Ubuntu). But please always add "Liberation Sans" and "Liberation Serif" to the other stacks too. You risk nothing doing it and they render very well when present (says "Liberation Sans" renders better than the default sans-serif this stack would fall back to).
caniuse shows green for all modern browsers, and this blog post from 2017 talks about Windows 7 and the Windows Classic theme. Where are the actual issues?
Imagine 10 pages of interface people talking about how mimicking standard OS controls allows blah blah – but IMO folks really just don't like how Arial and Times New Roman look.
I "discovered" this stack through VScode autocomplete when making my website several moons ago. It's a huge improvement in readability over the default serif font, and not much overhead is added!
The point of the system font stack is that your site’s typography resembles the typography of the entire platform. It might look differently on different platforms, but it matches the platform you’re on.
Sans-serif will get you ugly fonts, such as Arial on Windows, and likely DejaVu Sans or Liberation Sans on Linux.
True. The problem is the default browser settings. They are middling to bad, almost universally, and you cannot really expect visitors to fix their font settings before opening your webpage.
In a perfect world the defaults would look great, making sans-serif a viable choice and allowing the few users who really care (beyond 'it looks good') to do whatever they want.
Using different fonts on different platforms will be a problem for design because those fonts have different metrics, different character height and different optimal line interval, for example.
Arial is a cheap knock-off of Helvetica. Helvetica does look great in print or on high DPI screens, and Arial manages too, but it’s not so great if you’re dealing with a 96 DPI screen and small font sizes.
But you're not on that platform. You're on the browser. And short of every other web site adopting this stack (not gonna happen), it will just look weird, like an uncanny web site trying to look more native without being native at all.
The actual font rendered as sans-serif can be changed via a browser settings. But the system font stack is usually resolved to the same font for a given OS.
some of them even come with annotations as to why they make the choices they make.
Github's font stack is
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif, "Apple Color Emoji", "Noto Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
VS Code:
font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen, Ubuntu, Cantarell, 'Open Sans', 'Helvetica Neue', sans-serif
probably more "native" on mobile:
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Helvetica Neue", Arial, sans-serif;
apparently all modern browsers have this new shortcut that make it as simple as:
font-family: ‘system-ui’, sans-serif;
https://chromestatus.com/feature/5640395337760768