Skip to content
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

Use system-native font stack #11818

Closed
silverwind opened this issue Jun 9, 2020 · 11 comments · Fixed by #12114
Closed

Use system-native font stack #11818

silverwind opened this issue Jun 9, 2020 · 11 comments · Fixed by #12114

Comments

@silverwind
Copy link
Member

Webfonts in general bring the issue that the page can not render completely without the font download finishing, which gives us one of the following issues:

  • flash of invisible text (FOIT) which makes the browser render a invisible font until the download is done (equivalent to font-display: block and default behaviour in most browsers)
  • flash of unstyled text (FOUT) which make the browser render a system font and then replace it with the downloaded font (equivalent to font-display: swap)

Both are bad in their own ways and I think we should eliminate all web fonts and just use a sytem-native font stack. This would match us with GitHub and GitLab which both also use native font stacks and do not rely on any web fonts.

GitHub has:

font-family: -apple-system,BlinkMacSystemFont,Segoe UI,Helvetica,Arial,sans-serif,Apple Color Emoji,Segoe UI Emoji;

GitLab has:

font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Noto Sans", Ubuntu, Cantarell, "Helvetica Neue", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji";
@mrsdizzie
Copy link
Member

Could we do this now that 1.12 is released?

@silverwind
Copy link
Member Author

silverwind commented Jun 21, 2020

Yes, I plan to rework fonts. The only possible remaining font should be the emoji fallback, but it's kind of questionable benefit as it only really supports Chrome on Linux (Other OS do ship emoji fonts and Firefox can't parse the ttf file because a bug on their end last I checked).

silverwind added a commit to silverwind/gitea that referenced this issue Jul 2, 2020
- Use system fonts only for text to avoid FOUT
- Move font-awesome to npm/webpack
- Move NotoColorEmoji to web_src
- Remove presumably unneccesary 'PT Sans Narrow'
- Simplify webpack import exclusions

Fixes: go-gitea#11818
Fixes: go-gitea#11814
lafriks added a commit that referenced this issue Jul 6, 2020
- Use system fonts only for text to avoid FOUT
- Move font-awesome to npm/webpack
- Move NotoColorEmoji to web_src
- Remove presumably unneccesary 'PT Sans Narrow'
- Simplify webpack import exclusions

Fixes: #11818
Fixes: #11814

Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: Lauris BH <lauris@nix.lv>
@andreymal
Copy link

andreymal commented Jul 13, 2020

This is NOT system-native!

I have Segoe UI installed on my Arch Linux, but my system-native font is actually Ubuntu. This CSS will override system configuration and use Segoe UI instead of real system-native font.

The real system-native font stack will be enabled only if you will use font-family: sans-serif.

Also, issues mentioned here are relevant only at the first visit to website while the webfonts are not yet cached, so this is very minor and it would be best to get the Lato font back.

Also×2, "system-native" fonts often break website designs, so I don’t understand this hype. All websites that switched to "system-native" fonts began to look worse and less consistent for me.

P.S. font-family: system-ui is not yet working in Firefox, and this still overrides browser-level configuration in Chrome

@silverwind
Copy link
Member Author

silverwind commented Jul 13, 2020

This CSS will override system configuration and use Segoe UI instead of real system-native font.

Those font stacks are quite intricate. What is the "native" sans-serif font of Ubuntu? I'm happy to put it before Segeo UI as it's like never present on Windows. Also, you're seeing Segeo UI on GitHub, right?

Also, issues mentioned here are relevant only at the first visit to website while the webfonts are not yet cached

It's certainly an issue in some browsers (Firefox) that flash a different font on every page load and then replace it with the webfont, even if that webfont is in the cache. Also, system fonts are highly likely to contain many more language glyphs which can not be said from webfonts.

@andreymal
Copy link

What is the "native" sans-serif font

It is a font I selected in settings of my desktop environment or in browser settings (every browser allows to configure fonts). It can be any font.

Also, you're seeing Segeo UI on GitHub, right?

Yes

system fonts are highly likely to contain many more language glyphs

It seems this is the only real reason to use "system-native" fonts (okay, probably I got excited with "would be best to get the Lato font back" :).

Although this font-family is still not system-native, as I said earlier

@silverwind
Copy link
Member Author

I'm certainly not against trying to utilize system's sans-serif but I guess there must be a reason why most recommendations have it last.

@zeripath
Copy link
Contributor

@andreymal I have the same problem - I also have Segoe UI installed due to having to deal with dozers but Gitea is not unique in this Github also forces Segoe UI above sans-serif.

I've also noticed that DeJa Vu Mono has a number of emoji glyphs which are non-colored and can prevent colored emoji from appearing, e.g. ☺ and ✍ . There are other issues with DeJa Vu Sans's Emoji but I think we may have solved them already

@silverwind
Copy link
Member Author

I guess we could certainly tweak the font stack to prefer Ubuntu's default font over Segeo UI.

@CL-Jeremy
Copy link
Contributor

CL-Jeremy commented Jul 25, 2020

P.S. font-family: system-ui is not yet working in Firefox, and this still overrides browser-level configuration in Chrome
I think it’s really the browser’s job to implement system-ui properly.

Apart from that, I believe the semantics behind system-ui is really to ignore browser settings. I use Manjaro quite often (alongside macOS 10.10/10.15) and have tuned the OS to use a custom font stack with fontconfig, which the browser happily matches with system-ui. Both Chromium and Firefox pick up those fonts properly (though for some reason, Firefox chooses to use Yu Gothic UI by whatever criteria it presumes unless I remove system-ui from the stack, which makes it use my in-browser settings to match sans-serif).

Bildschirmfoto von 2020-07-25 04-45-24

Bildschirmfoto von 2020-07-25 04-45-26

And the quirks don’t end there. On macOS, all browsers, with the sole exception of Safari, matches sans-serif to one of the two traditional Chinese system fonts (PingFang HK/TC, for Hong Kong and Taiwan respectively) which I defined initially during the introduction of CJK :lang-specific font stacks. I’m not gonna bomb this thread with screenshots, but my Chromium chooses Taiwan and my Firefox favors Hong Kong (my OS is in German, so I believe it depends on the language preference stack configured in the OS, which originated from macOS but has spread to various OSes lately). This was not a problem up to 1.11.x, where sans-serif was still in the last place of the font stack.

I really take #11045 as a good chance to have these little problems solved altogether. I agree the definition “system-native” is debatable, but please bear in mind that most OSes do not give users much freedom to fiddle with the UI (since they’ve spent remarkable amount of time and budget to factory tweak them) and moreover, most users aren’t gonna prefer customization over usability for a tool like this. I myself am still using Lato though (and thus much appreciate the idea to use CSS variables, which I first noticed in Nextcloud, also switched to a native font stack not long ago).

Edit: sorry, wrong issue reference!

@silverwind
Copy link
Member Author

I wonder if it'd be possible to remove all the explicit fonts and user either system-ui or sans-serif. They both seem to essentially do the same thing to me but I guess system-ui uses more "modern" font choices than the traditional sans-serif. Certainly worth experimenting once all browsers support it (waiting on Firefox).

@CL-Jeremy
Copy link
Contributor

Well, even if, say, Firefox manages to fix this bug in a few months, it’ll still take much longer for users to upgrade (actually, I myself am using a legacy XUL-based Firefox fork on some legacy systems, which is of course much more modern than IE 11, for which the support hasn’t officially been dropped yet).

but I guess system-ui uses more "modern" font choices than the traditional sans-serif.

Again, the semantics are different. system-ui does not really presume display of “content”, but rather “near native web interface elements”. By contrast, sans-serif, in the long history of WWW, has always presumed itself being used for some kind of “content”, starting with plain text blocks in an non-stylized static document, where IMHO the browser’s settings have been, and still should be used for. Its usage as a last resort in most occasions relies on the fact that either the user or the OS is providing this fail-safe solution so as to at least make the valuable content of the web page comprehensible (thus the ability to display the theoretically maximum number of characters the OS is, by default, capable of displaying).

What this means is, whenever sans-serif is used, the fallback stack is completely controlled by the OS itself (that is, if the browser doesn’t “misbehave” as per my example of Chromium and Firefox making different choices for the exact same fallback stack). Examples for this in the Chinese context is the use of highly uncommon characters, such as certain Hong Kong-specific dialectical supplements, supplementary character variants and technical neologisms (such as newly discovered elements), which could result in visual discrepancy even in the same typeface. As long as sans-serif is used (in this case it doesn’t matter if it’s sans-serif, serif or monospace, the OS could only choose SimSun, which is a serif font), it would shadow whatever font that comes later in the stack, even emojis.

And even with system-ui, there are corner cases where explicit choices are much more favorable. The other example I have given above shows Yu Gothic UI, the Windows 8.1 replacement of Meiryo UI for native UI elements in Japanese. This is by far the most utilitarian Modern typeface one may encounter, as it basically copied all the narrowed-down kanas from Meiryo UI in order to keep the original UI designs pixel-perfect. If by any chance the browser picks up this font in any occation, it should be regarded as a mistake (in the system-ui example above, a bug). In the current font stack I have specifically chosen Yu Gothic for its visual friendliness at higher resolutions (in contrast to Meiryo, which was mainly designed to be used at lower resolutions, accompanied by ClearType). This particular font could (and IMHO should) also be leveraged on older OSes if Office is installed or a specific optional supplementary update from Microsoft is applied.

So much on this topic, and sorry for the long passages. I just hope to be able to help a bit by expressing my concerns on the complexity of this task.

ydelafollye pushed a commit to ydelafollye/gitea that referenced this issue Jul 31, 2020
- Use system fonts only for text to avoid FOUT
- Move font-awesome to npm/webpack
- Move NotoColorEmoji to web_src
- Remove presumably unneccesary 'PT Sans Narrow'
- Simplify webpack import exclusions

Fixes: go-gitea#11818
Fixes: go-gitea#11814

Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: Lauris BH <lauris@nix.lv>
@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants