We are switching to system fonts on May 10, 2021

Question

Update 3 - The changes from round 2 are live, but with one notable exception: On Linux, we spec’d “Liberation Sans” and “Liberation Mono”. Did some digging on that PR and installed a few Linux VMs and found Liberation to be the best way to normalize across Linux distros. It also solves an issue where Ubuntu Mono—regardless of how you feel about the typeface—is smaller than its sans-serif counterpart.

Also noteworthy, we aren’t touching webkit antialiasing right now. I was reacting to a change in macOS 11.3 that removes the ability to set antialiasing at the OS-level. I hope it’s a bug, and is patched up in 11.4.

Plenty of little bugs to squash yet, and I’m chipping away at them. If something feels off on Windows, do revisit your ClearType settings. I’ve seen some folks realize with this switch that they were running some non-stock antialiasing.

---

Update 2 - Alright folks, got some follow-up for you. You can see I’m considering some changes over at the Stacks repo. Sidenote: did you know our front-end library is open source and y’all can see what we’re up to?

1. macOS and iOS continue to get San Francisco
2. Windows continues to get Segoe, but we drop system-ui since it isn’t quite ready for primetime.
3. Linux gets “Arial” which is never Arial, but often Liberation Sans, or Noto, but maintains the status quo.
4. Android gets Roboto, but we don’t specify it since it was clobbering Debian
5. If all else fails, sans-serif.

As for general font sizes, I think our fonts have always been too small. The base font size is 13px and we even show some bits of UI at 11px. I’ve got long term goals of bumping those up a point or two. I hear y’all with aging eyes. Mine are also aging—always have been, always will be 😛

I’ve read every comment and answer here and I think this strikes a balance between how we want to move forward and issues people have had in good faith. I’ll get to chipping away at the small issues once we iron out the bigger ones.

If this follow-up works, I’ll make sure to update the screenshots in this original post in a third update.

---

Update 1 - These changes are now live!

TL;DR We’re shipping system fonts as our default font stack. We plan to do this on May 10th, 2021.

What?

We’re planning on specifying system fonts on Stack Overflow and the Stack Exchange Network. On macOS and iOS, you’ll see things set in San Francisco. On Windows, you’ll see Segoe. On Android you’ll get Roboto. Ubuntu will show, well, Ubuntu. We’ll also use their monospace equivalents when writing in code or rendering keyboard keys.

OS	Sans	Mono
macOS	San Francisco	San Francisco Mono
iOS	San Francisco	San Francisco Mono
Windows	Segoe UI	Consolas, or Cascadia Mono, Segoe UI Mono if you've installed those manually
Ubuntu	Ubuntu	Ubuntu Mono
Android	Roboto	Roboto Mono
Chrome OS	Roboto	Roboto Mono
Fallback	sans-serif	Menlo, Monaco, Consolas, monospace

We’re leaving serif fonts alone so those will stay as Georgia, Cambria, Times New Roman, Times, and then serif as a fallback. We really don't do much with serifs anyway, and we don’t want to mess with the themes that rely on them.

Here’s the exact font stack we’ve specified that’ll go live on the 10th.

@ff-sans:
    system-ui, -apple-system, BlinkMacSystemFont, // San Francisco on macOS and iOS
    "Segoe UI", // Windows
    "Ubuntu", // Ubuntu
    "Roboto", "Noto Sans", "Droid Sans", // Chrome OS and Android with fallbacks
    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
    "Ubuntu Mono", // Ubuntu
    "Roboto Mono", // Chrome OS and Android
    Menlo, Monaco, Consolas, // A few sensible system font choices
    monospace; // The final fallback for rendering in monospace.

Why?

Mark Otto put it really well on his personal blog, documenting GitHub’s rationale for switching. Like GitHub, our original font stack used Arial across macOS, iOS, and Windows. Arial was first created in 1982, and has served the web well for decades. But technology moves on. Modern system typefaces look better on both new high DPI screens, and old screens alike. Apple’s San Francisco and Microsoft’s Segoe both look great on retina displays, have more expressive weights, and improve readability across all contexts. With more weights, we can have better hierarchy. We can also get more expressive. For example, in dark mode, we could drop our font weights a bit for better readability.

But what about consistency?

We originally chose Arial because it was available on the widest set of devices, allowing us to have a consistent experience wherever you were. However, Arial doesn’t ship with Linux distros or Android devices. We’re currently only achieving consistency between macOS, iOS, and Windows, leaving 2 platforms to choose their system font. We’d rather have the consistency be shifted to the device itself—when viewing Stack Overflow on iOS, it’ll feel that much more native in San Francisco. Same with Android, which is already being displayed in Roboto.

We should also note that prior to these changes, our monospace font stack varied wildly. Now you'll have better consistency between sans and monospace, since we'll do our best to choose the right pairings.

Will my Stack Exchange site lose its custom font?

Nope! This change will not affect sites that have their own typefaces. Sites like Christianity and English will still be displayed in their custom fonts.

Future possibilities

If consistency were the absolute goal, we’d ship our own custom font. I would love to be able to truly express our brand through a typeface, but that means users would have to download custom fonts and wait for them to display. We’d also have to cover international character sets. Displaying custom fonts is getting more realistic every day at our scale, so we may revisit that choice at some point, and come back to a more consistent experience. System fonts let us modernize in the meantime without too many drawbacks.

Also, since a lot of our site is built using our design system, we can store these font stacks as CSS variables. We could allow users to more easily specify dyslexia-friendly typefaces, or load their own entirely.

Some screenshots

Safari on macOS

Firefox on Windows

Firefox on Ubuntu

So what now?

When this change drops, we could use your help in discovering any bugs—things like unexpected alignment, or any questionable bits where we clearly got the wrong typeface.

Answer 1

support

Now that this has gone live... Serious question:

How do I go back?

The new font chosen (Using Firefox in Windows 10) feels substantially harder to read and has some gnarly issues with anti-aliasing, to the point that italic text is nearly painful to read, especially in comments.

Answer 2

Multi-disciplinary designer chiming in here.

However, Arial doesn’t ship with Linux distros or Android devices. We’re currently only achieving consistency between macOS, iOS, and Windows, leaving 2 platforms to choose their system font.

Why are you not loading the Arial webfont?

We’d rather have the consistency be shifted to the device itself—when viewing Stack Overflow on iOS, it’ll feel that much more native in San Francisco. Same with Android, which is already being displayed in Roboto.

What is the advantage of feeling more native? Is Stack Exchange not its own brand with its own identity?

We should also note that prior to these changes, our monospace font stack varied wildly. Now you'll have better consistency between sans and monospace, since we'll do our best to choose the right pairings.

You can still select the right pairings going forward and have it be consistent across each platform.

If consistency were the absolute goal, we’d ship our own custom font. I would love to be able to truly express our brand through a typeface, but that means users would have to download custom fonts and wait for them to display.

You can achieve consistency without making your own custom font. There are plenty of websites that download off-the-shelf well-designed fonts. Text is rendered and then styled, so even if there was a delay in loading the generally small (~100kb) font file, the text would be displayed in the default browser font temporarily—making it still readable as it doesn't require any "waiting" for the text itself to display. Regardless, the font file is downloaded once on first visit.

---

As a designer, this move baffles me. I use a Windows computer, an Android phone, and an iPad tablet and each one will look different from each other, but look native to the device they're on? I fail to see the real reason for this move. What is the advantage of looking native to a device? Has any other company done this (purposefully) and if so, what was the outcome? Do your designers on staff agree with this decision?

I'd love to hear any and all comments or thoughts.

Answer 3

Why Segoe UI? Why UI fonts at all?

Segoe UI is, as its name implies, a font designed for UI. As other posters have said, it is actually somewhat harder to read. The lines have a lower weight and the x-height is smaller. You need to change the font size or you'll reduce visibility and accessibility.

Though, honestly, UI fonts are not designed for reading larger amounts of text. Using font-family: ui-font makes the most sense when you are mimicking a window, so that the app looks more native, but not for large amounts of text.

This seems a move made without any concerns about accessibility. Users should have been told about the propose change well in advance and given a chance to voice possible flaws so that everything could be worked out. I do not understand why StackExchange continues to make decisions without taking advantage of one of its biggest assets: the combined knowledge and experience of so many subject-matter experts.

I suspect that this change is actually more of a fad than anything. Of course Github did it--they're owned by Microsoft. Microsoft, however, is historically not very good at design.

Answer 4

Update

As of "Update 3" things look about like they used to for me on Linux Mint, thank you for hearing the feedback and making the adjustments. (Took a quick look on Windows. I can't say it looks good to me. Better, but not good.)

The process part of the below remains pertinent, but again, thank you for listening.

---

Two issues

1. The change is not good, it makes things much harder to read

2. The process of the change was awful

Apologies for being blunt below, but I'm cross I even have to write this. Has Stack Exchange learned nothing about community engagement and change management? And I'm in a hurry because I have actual work to do, so wordsmithing isn't a priority.

The change itself is not good

This change makes it really hard to read the site on Brave (Chrome-like) on Linux Mint 20. This isn't a moving the cheese thing. This is actually making my eyes hurt.

The text seems smaller ("gee, thanks" says the 54-year-old man), line height and letterspacing is...off... I'm not a fonts guy so I don't know the ins and outs of why, but even zooming the text to a reasonable size again it's still really hard to read (and the layout gets hinky).

Sure, I could use a userscript to fix it, and then have to update that user script every time you make another change like this instead of fixing things that actually matter (like Stack Snippets), and deal with the inevitable bug — sometimes quite subtle bugs making you miss important information — related to using a userscript that you don't test with (why would you?) before doing updates.

I should not have to do that just to help people on Stack Overflow.

See the end of this post for pictures of how it looks on my system, but here's a side-by-side between now and May 6th (I suggest downloading and viewing at 100%):

I'm surprised to find that the font-size values didn't change (because it seems smaller), it's "just" the font-family. But it's a big negative impact on readability, on my system anyway.

Making large blocks of text readable online is surely a solved problem? Blog after blog has perfectly readable text (much more readable than mine; I need to fix it). News sites. Etc., etc., etc.

The process of the change was awful

Reading and writing text is what using Stack Exchange is all about. Changing the text is a huge deal.

I visit Stack Overflow every day, several times a day. There was no advance warning of this change that I saw (if it was in the "The Overflow Blog" or "Featured on Meta" lists, pardon me for focussing on questions and answers — a change this big should be a banner I have to dismiss). I take it the only announcement of it was in the "Featured on Meta" list that I, like many, don't pay much attention to.

I was going nuts trying to figure out what button I'd accidentally pressed to screw up my text like this. Again, a banner was called for.

Maybe I'm not representative, though I see I'm far from alone with finding the new font harder to read.

Having used a proper process would at least reassure me that it was taken seriously and done properly even if it negatively impacts me personally. Here's an off-the-cuff of how this change could have been handled better IMHO (but I'm not a process consultant, it can probably be done even better):

1. Requirements: Is a change really needed?

Ask the users, in particular your regular power users: Do we need to change it, or is it fine as is?

2. Requirements: Why is a change needed? What needs changing? How?

Ask the users why they feel a change is needed, what needs changing, and how.

3. Implementation: Options

Do up mock pages showing:

• Original
• Option A
• Option B
• Option C
• Option D
• Option E

and collect feedback on the options, narrowing it to (say) two.

4. Implementation and Communication: A/B Testing

Announce the upcoming change and ask people to opt into being randomly assigned one of the test groups. Get feedback and measure engagement vs. previous levels of engagement. Be sure to get a representative sample testing (including young people, older people, people with "perfect vision," people who need corrective lenses, ...).

5. Implementation: Optional

A change this big is never going to be okay with everyone. Provide an opt out. Yes, it incurs maintenance cost (or more accurately, making the change incurs maintenance cost; leaving it alone wouldn't have cost anything). Review annually to see if you can retire the opt-out.

Or here's an idea: Have options. There is no one-size-fits-all. Offer a two or three presentations.

6. Implementation: Finalize

Finish the identified change without hundreds of !important CSS rules, not least so userscripts or similar can reasonably handle undoing it.

7. Communication: Advance warning

Banner-level warning of the upcoming change with a preview link so everyone can see what it will look like to them.

8. Communication: Notification

Banner-level notification the change has been put in place.

Here's what it looks like

(please click to see the full size versions)

Question list - unzoomed:

Question - unzoomed:

Question list - zoomed 110%:

Question - zoomed 110%:

Question list - zoomed 125%:

Question - zoomed 125%:

Posting an answer - unzoomed:

Posting an answer - zoomed 110%:

Posting an answer - zoomed 125%:

Comments - unzoomed:

Comments - zoomed 110%:

Comments - zoomed 125%:

Answer 5

As you consider the font stack, please do consider revisiting this very popular request: "Can we at least select our fonts?". Yes, it is marked status-completed, but the "New plan is the old plan, mostly" and these fonts are still inappropriate for a significant number of sites.

Answer 6

Arial was first created in 1982, and has served the web well for decades. But technology moves on. Modern system typefaces look better on both new high DPI screens, and old screens alike. Apple’s San Francisco and Microsoft’s Segoe both look great on retina displays, have more expressive weights, and improve readability across all contexts.

To me, Segoe UI looks like a cartoon comic font. It's really bad, and unreadable. And I am not alone in thinking this.

Also, IMO Arial was perfectly readable on my HP 24mh monitor, with my Nvidia GeForce GTX 1050 Ti video card (this is new tech on the market). Yet the font is unreadable on this new technology. And I don't see any data that proves system typefaces look better than Arial on new devices.

Is there any paper which uses data collected from people that states that system fonts are more readable than Arial? Really, one of the only reasons this change was made was because GitHub did it.... :\

If you want to switch the font, please make it something other than Segoe UI for Windows.

Finally, italics are a pain to read in the new font.

Answer 7

Rapid observations

Interesting change. Confusing title. Strange timing.

---

Interesting change

This looks to be a network-wide change, except when it isn't. Any site not already customized will switch to the new version, while customized sites get to keep what they have (or don't get the latest and greatest change). So long as the results are still readable, or no less readable than the current settings, it's fine. Telling the difference between uppercase /ˈaɪ/, lowercase /ˈɛl/ and Arabic numeral one can be difficult at a glance. Similar difficulties exists between uppercase /ˈoʊ/ and Arabic numeral zero. With luck the font served will resolve the issue.

Confusing title

The term "system fonts" made me hopeful, at first. Thinking to myself that now whatever fonts I've set my system to use for serif, sans-serif and mono space would be used in my browser as well. Well, the title was promising in that regard. Rather, if the change works as intended, the site will use a font which my OS supposedly ships as the default "system" font. Well, for the "top five" anyway: Android, ChromeOS, Windows, MacOS, and iOS.

Strange timing

Of all the things needing developer and designer attention on the network, this seems the least often mention, or requested, change. I've no idea how many sites have been out of Beta, or for how long, waiting on a customised theme, even a tiny bit to make them "unique" within the network. As mentioned in a comment, dark mode was introduced to SO over a year ago. Applying dark mode to the majority of the sites would seem to be less work than selecting and testing a new font stack system wide.

---

What I think

(All in random order)

The "Why" section references a GitHub blog as covering the reasons for switching. The same blog entry explains why they dropped the Ubuntu font, yet it appears to be included in the font stack here. If GitHub had issues with that font using their modest, by comparison, site styling, what problems can be expected within this network?

The table of font to OS association contributed to my initial thought that the "system font" would be applied to the site. Using a custom font stack, which is supposed to have the site's fonts match the device's system font to create a seamless user experience only works until the user has selected a different font for their device. Worse, if the user has selected a different font they may be upset that SE refuses to acknowledge that choice.

Even if it's not a custom font for SE, though that was stated as a possibility in the future, using a downloadable font, with decent fallback options in the font stack seems like a better option for creating a "brand" feel rather than trying to create an "app" feel which is so demonstrably fragile. The wait for it to download, even on a mobile device should be minimal, and is likely cached by the device for future page loads as well.

Also interesting is the desire to modernize the style, but only for the sans-serif and mono space fonts. If the "old is bad and new is good" is to be part of the rationale, why leave the old serif fonts untouched? Times and Times New Roman (1931) are older than Arial (1982), and Georgia (1993) is not much newer.

As mentioned earlier, the differences between uppercase /ˈaɪ/, lowercase /ˈɛl/ and Arabic numeral one can be difficult at a glance, as can the difference uppercase /ˈoʊ/ and Arabic numeral zero. Finding a set of fonts, especially in the mono space group, would probably do more for the users than aiming to update the fonts just because the current set is "old".

I frequently see references to the design system (Stacks), and how much easier it makes design change implementations. In this case because the font stacks can be stored as CSS variables. Somehow, whenever other, user desired, design changes are mentioned, the typical reply is akin to the idea that it's too hard, or take too much time, or involved too many resources. I've yet to decide if the Stacks took is helpful or not, in actual application by the team.

---

I'm not opposed to a fresh new look. It's even a good thing to keep a fresh feel to the site. I also do not personally care which fonts are used, or even if serif or sans-serif is the norm. The timing, while short, isn't a problem, nor would it be if there had been no notice at all. Odds are that less than half the users will even notice the change. I am a bit surprised that this change was not significant in requests or complaints on meta yet seems to have been fully developed without feedback from users.

It's my hope that the reading won't be any more difficult than it is.

Answer 8

I don’t like this at all. Here is a UserStyle to revert:

/* ==userstyle==
@name Stack Exchange
@namespace Steven Penny
@version 1.0.0
==/userstyle== */
@-moz-document
domain("stackexchange.com"),
domain("stackoverflow.com"),
domain("superuser.com") {
   body {
      --ff-mono: Consolas;
      --ff-sans: Arial;
   }
   .topbar-dialog .modal-content .message-text h4,
   .topbar-dialog,
   header {
      font-family: var(--ff-sans) !important;
   }
   .full-diff .content,
   .wmd-input,
   code {
      font-family: var(--ff-mono) !important;
   }
}

https://github.com/openstyles/stylus

Answer 9

Update: If you encounter this error in Chrome, turning on the "Use hardware acceleration when available" setting should solve this issue.

Code blocks in deleted posts are practically unreadable on Windows 10 (Chrome, 200% DPI).

Answer 10

feature-request

I currently use SE on multiple devices, with multiple OS' (Windows, Mac OS, Android). Personally I would prefer a uniform site on all these devices, also as not to break my muscle memory (seeing that text will change in length buttons will inadvertently shift in the layout).

I know that you decided different, which is a great option for users using a single device. But at the same time SE also has the history of being highly customizable using one's profile. It would be great to have such a setting for the font as well. That way we can override the system font with a font of our picking. This would also be a great feature for those that have less then perfect eyesight and want to use a more accesible font.

Answer 11

I see a lot of people are upset about the change, particularly Windows folks. Who would've thought Microsoft's Segoe is not a great typeface... :)

My question to the team is: Why not simply this?

@ff-sans: sans-serif;
@ff-serif: serif;
@ff-mono: monospace;

Browsers allow everyone to easily set their preferred default, serif, sans-serif, and monospace fonts directly in the settings. It allows them to render text in every supported language using the most appropriate and readable font. Users with dyslexia can pick fonts that help them read, without having to install extensions.

On Windows, people may be used to Arial because, at least in Firefox, Arial is in fact the default sans-serif font.

If you truly want everyone to have a fast, coherent user experience appropriate for their device and needs, I think it makes more sense to use the standard font family specifiers. I'm not saying that Arial is better (IMO it's about as bad as Segoe), nor that every system has a great preset of default fonts (Windows sure doesn't), but if an experience consistent with the user's environment is what you're after, this is one sure way to get there.

Answer 12

bug status-completed

Could you pretty-please not hardcode any of the following CSS selectors with the new font-family and actually use the --ff-* CSS variables without !important everywhere like you promised? Thanks.

Compiled from https://cdn.sstatic.net/Sites/stackoverflow/primary.css:

• code
• pre
• textarea.wmd-input,textarea#wmd-input
• .topbar-dialog
• .topbar-dialog .header h3
• .topbar-dialog .header h3 a
• .topbar-dialog .modal-content .message-text h4
• .topbar-dialog .pinned-site-editor-container .remove-pinned-site-link a
• .top-bar
• #user-menu
• .full-diff .content

Answer 13

bug status-completed

The highlight surrounding OP's username in a comment overlays parts of the comment's text.

^{Windows, Chrome 64-bit}

Answer 14

bug status-completed

I guess someone must really hate me.

This is Firefox ESR 78 on Debian picking Roboto. A font badly hinted and even worse kerned, at this DPI at least. And I think I liked the look of Arimo more anyway… (My actual UI font is Noto Sans Display SemiCondensed, which looks better, but I still wouldn’t want it here. I never bothered installing Ubuntu fonts.)

Answer 15

status-completed

Could you increase the default font size of Ubuntu Mono?

This font is known to display about 2 points smaller than most other monospace fonts (as commented on here, and discussed further here). It would be great is SE accounted for this and increased the size with 2 points instead of the current setting which makes monospace text on the Linux version of SE is harder to read because it is so small.

Yes, it is possible to change all font sizes in your browser settings, but the issue here is specific to Ubuntu Mono and there is no way to control that from your browser settings (and the default SE UI should be made accessible on all platforms).

Here is an example of how small the font is when writing this post (compare to the rendered version):

On SO it appears even smaller and it is quite difficult to read without squinting which makes for a less than ideal user experience.

Answer 16

feature-request

I don't understand why you used the system-ui font for the default, instead of sans-serif. That font is not adjustable, and you are stuck with whatever horror the underlying OS chooses.

On Windows I also have some options to adjust rendering of the standard UI (ClearType), to make it more readable, but browsers use their own settings.

I don't know about other browsers, but Chrome allows customizing fonts that will be used for sans-serif, serif...

An additional issue is font size. On older Windows, the default font size was 8 points, but with introduction of Segoe UI that size changed to 9 points, because Segoe UI is harder to read on smaller sizes.

I don't have an issue with larger fonts that also use darker color, but small fonts with low contrast are impossible to read.

If you don't want to switch to sans-serif then at least increase the size and contrast of the smallest fonts - like in tags and also increase their contrast.

---

Using user scripts is simply not an option for the vast majority of users.

Answer 17

Custom Fonts User Script: Revert or Improve the Font Updates

(Stack Apps)

For those of you who prefered the old appearance, or would like a different font to appear in code blocks or across the site as a whole, Custom Fonts is a user script I wrote this morning to allow just that.

Features

Custom Fonts allows rules to be set for different sites, which can specify a sans serif, serif, and monospace font. A default can also be specified, allowing you to choose between sans serif and serif for any site.

Custom Fonts initially doesn't change anything (unless you download one with a preset), but on lines 26 and 27 are rules that revert all of Stack Exchange to its original fonts (once un-commented). Custom rules can be written, and there is a short reference in the comments under the Rules object.

Download

Custom Fonts is a user script, meaning that it requires Greasemonkey (Firefox or browsers that support Firefox extensions) or Tampermonkey (Chrome or browsers that support Chrome extensions) to be installed.

Custom Fonts 1.2.4

Custom Fonts 1.2.4, with original fonts

Custom Fonts 1.2.4, with Roboto + Roboto Mono

Answer 18

status-deferred

Can you consider adding "Segoe UI Variable Text" before "Segoe UI" in the font stack for Windows?

Microsoft will gradually update Windows UI with this new font in the future: Announcing Windows 10 Insider Preview Build 21376 | Windows Insider Blog

We are introducing Segoe UI Variable which includes an optical axis so that font outlines can scale seamlessly from small to larger display sizes. Segoe UI Variable is a refreshed take on the classic Segoe, now with improved legibility at small sizes, and much improved outlines at display sizes.

Historically, fonts for printing small text were designed differently than fonts designed for large display text. Segoe UI was originally designed to work at 9pt, which makes it a great font for that size, but limits expression at large sizes and lacks legibility at even smaller sizes. Segoe UI Variable solves this by using a new version of Segoe that uses variable font technology to dynamically offer great legibility at very small sizes, and style at large sizes.

Segoe UI:

Segoe UI Variable:

Answer 19

status-completed

We shouldn't assume that system-ui corresponds to Segoe UI font on Windows.

For example, if your system language is set to Simplified Chinese, the default font would be Microsoft YaHei UI; if the language is set to Japanese, the default font would be Meiryo UI. And both of these fonts look unbalanced when displaying Latin characters.

The worst part is that the system default font cannot be changed without completely messing up all the localized texts in the system.

Here's a comparison between old Arial font (right) and new system-ui (left) which is Microsoft YaHei UI on my PC:

So I suggest to place "Segoe UI" before system-ui or really anything that can ensure that it never falls back to system-ui on Windows.

Answer 20

status-completed

Ubuntu 20.04 / Chrome / Stack Overflow - The new font and font-size makes it harder to read both plain text and code.

Why is the text in the new code blocks so tiny?

Before

^{(with a user-script to get the old darker background in code blocks and spacing between lines)}

After:

^{(with all user-scripts disabled)}

Answer 21

status-declined

Please bring back the old line-height 1.3 setting

I find new fonts (I'm on Windows, so Segoe UI) look even worse with the current settings. It's more comfortable to read with thinner fonts at more compact line heights.

Screenshot for current (1.5):

Screenshot for line-height: 1.3

Answer 22

status-completed

OMG, MY EYES !!!

---

The new MacOS fonts are very "slim" and they are very hard to read when the color is not black (eg: blueish or grayish).

Please, consider reverting this change until more research is being done and more issues are fixed.

---

Updating to system font would have been totally normal move, IF:

• those fonts would have been readable.

The font (as of Thu, May 13th) is abysmal on MacOS (usually the OS that designers use), and there is no reason to expect them being any better on other platforms.

Especially painful:

• linked posts on the right sidebar:

• comments:

• homepage:

Answer 23

Here's a userstyle I threw together that should fix both sans-serif and monospace. It also fixes hardcoded fonts within textareas and codeblocks that don't use the font variables for some reason. This should work in both Stylus (tested) and Stylish (untested).

@-moz-document domain("stackoverflow.com"), domain("stackexchange.com"), domain("askubuntu.com"), domain("superuser.com"), domain("serverfault.com"), domain("stackapps.com"),
domain("mathoverflow.net") {
body {
    --ff-sans: Arial, "Helvetica Neue", Helvetica, sans-serif;
    --ff-mono: Consolas, Menlo, Monaco, Lucida Console, Liberation Mono, DejaVu Sans Mono, Bitstream Vera Sans Mono, Courier New, monospace, sans-serif;
}

code, .s-prose code, pre.s-code-block, textarea.wmd-input, textarea#wmd-input, .full-diff .content {
    font-family: var(--ff-mono);
}

.top-bar, .topbar-dialog, #user-menu, .topbar-dialog .header h3 a, .topbar-dialog .pinned-site-editor-container .remove-pinned-site-link a, .topbar-dialog .modal-content .message-text h4 {
    font-family: var(--ff-sans) !important;
}
}

https://gist.github.com/SuperStormer/60a5e5c7e9549e9ed865a579df6f11be

Answer 24

A bit of a crosspost -

A recent change in the 'design' of Cascadia Code mono has rendered italic fonts to look cursive. When composing a post - the text area is in monospace. Specifically - when composing a post in the teams or "alpha" editor - using italics will result in text looking like this:

The font used for monospace italics on Teams (when composing a post in Markdown mode) are a little hard to read. It might be my dyslexia but, the r, f,l and s are... indistinct and significantly harder to read than the fonts used elsewhere. I'm *reasonably* certain, as someone who abuses italics for effect that this change happened *after* an update on the *OS* end - which might be an issue with using a font that seems to be in development, and I suspect an unintended, and unexpected change.

Regular Monospace looks fine:

Interestingly, the 'regular' editor doesn't have this issue since it doesn't show styles inline. It also apparently affects italic monospace in comments.

I'm on Windows 10 (build 19043) and am running Vivaldi 3.8 (while unsupported, it's another Blink/Chrome-based browser). I suspect, but I am unsure if the May "Feature update to Windows 10, version 21H1" might have triggered this change.

Answer 25

Have you considered harmonizing fonts used for MathJax and prose?

SE sites dedicated to natural science such as Chemistry.SE, Physics.SE and 40 other sites heavily rely on MathJax for written communication. There always has been a font family mismatch between the typeface used for mathematics and plain text. For example, on Chemistry.SE we deal with two fonts (MathJax TeX and Georgia) that simply look awful used together, not to mention Georgia is overall a poor choice of font for technical writing. We even had a brief discussion on this matter: Should chem.SE use Georgia font?

None of the aforementioned system fonts would look balanced together with MathJax at this point, and the sans fonts will be alienated from the default MathJax TeX font to the point the posts will look terrible typographically.

I realize it's a long-standing issue that cannot be immediately solved, and MathJax is a Ding an sich which doesn't help much. However, please consider the proposition of keeping both font families harmonized, or at least looking remotely similar.

One suggestion (albeit quite a bold one) would be to switch MathJax 2.7's default font to STIX General for the sites using MathJax, and list STIX as the primary font in ff-serif field. STIX is an open-source serif font beloved by many scientists for its canonical appearance and wide variety of glyphs for special characters readily available.

Answer 26

status-completed

Ubuntu font is great for titles and fine for body text; on the whole it's a really nice improvement. BUT the code blocks are harder to read and don't look good. Ubuntu mono is too narrow.

---

A nice workaround for this was suggested to me by Eliah Kagan - one can install the free-as-in-freedom Cascadia font which is higher in the stack.

I did sudo apt install fonts-cascadia-code on Lubuntu 20.04 - see the repo if your distribution/version hasn't packaged it.

Cascadia is much more readable to me than Ubuntu mono and looks a lot better than the monospace fonts from the old stack as well imho.

Answer 27

The new fonts are grim on Mac Safari + Chrome - really terrible.

Sorry - but the system UI font is just that: for my UI. Not for reading lots of text at speed. I can genuinely feel myself reading slower with the system UI font as compared to Arial.

Yes, I realise they're both sans serif, but the UI is more difficult to read than Arial, end of. Maybe it's the small inconsistencies in Arial that means it's easier for the eye to "grasp" the text; much like ragged-right and that weird dyslexic-friendly font are both easier than pretty much any other layout or font.

Basically - the more rounded / consistent the font is, the more difficult it is to read at speed. That's why serif is consistently quicker to read.

I'm not coming here to look at pretty text. I'm coming here to quickly get answers to stuff, and the speed at which I'm able to read the text is therefore very important.

_{(I am unable to comment on any of these as I don't have reputation on meta.)}

Answer 28

bug

The "Inbox" text at the top left of the inbox looks like a "Nbox" with a bold N on Windows/Chrome:

Answer 29

Is this change fully verified if it applies to sites that use non-English languages?

Our site (So.ja) took seven years until the design bug due to font specification was fixed.

Answer 30

I'm not 100% sure, but I think the update caused the blue badges on the profile page tabs not to be centered vertically anymore:

(Firefox, macOS)

Here is an example how it looked like: