github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-07-15 20:09:18 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Use system-native font stack #5520

New Issue
Closed
opened 2025-11-02 06:27:38 -06:00 by GiteaMirror · 11 comments
GiteaMirror commented 2025-11-02 06:27:38 -06:00
Owner
Copy Link

Originally created by @silverwind on GitHub (Jun 9, 2020).

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";
Originally created by @silverwind on GitHub (Jun 9, 2020). 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"; ````
GiteaMirror commented 2025-11-02 06:27:38 -06:00
Author
Owner
Copy Link

@mrsdizzie commented on GitHub (Jun 21, 2020):

Could we do this now that 1.12 is released?

@mrsdizzie commented on GitHub (Jun 21, 2020): Could we do this now that 1.12 is released?
GiteaMirror commented 2025-11-02 06:27:39 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (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 commented on GitHub (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).
GiteaMirror commented 2025-11-02 06:27:39 -06:00
Author
Owner
Copy Link

@andreymal commented on GitHub (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

@andreymal commented on GitHub (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
GiteaMirror commented 2025-11-02 06:27:39 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (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.

@silverwind commented on GitHub (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.
GiteaMirror commented 2025-11-02 06:27:39 -06:00
Author
Owner
Copy Link

@andreymal commented on GitHub (Jul 13, 2020):

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

@andreymal commented on GitHub (Jul 13, 2020): >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
GiteaMirror commented 2025-11-02 06:27:39 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Jul 13, 2020):

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.

@silverwind commented on GitHub (Jul 13, 2020): 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.
GiteaMirror commented 2025-11-02 06:27:40 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Jul 13, 2020):

@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

@zeripath commented on GitHub (Jul 13, 2020): @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
GiteaMirror commented 2025-11-02 06:27:40 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Jul 14, 2020):

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

@silverwind commented on GitHub (Jul 14, 2020): I guess we could certainly tweak the font stack to prefer Ubuntu's default font over Segeo UI.
GiteaMirror commented 2025-11-02 06:27:40 -06:00
Author
Owner
Copy Link

@CL-Jeremy commented on GitHub (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!

@CL-Jeremy commented on GitHub (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](https://user-images.githubusercontent.com/1714243/88447501-41748d00-ce34-11ea-9381-8d83da860e3c.png) ![Bildschirmfoto von 2020-07-25 04-45-26](https://user-images.githubusercontent.com/1714243/88447502-43d6e700-ce34-11ea-80da-0791cafdd087.png) 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!
GiteaMirror commented 2025-11-02 06:27:41 -06:00
Author
Owner
Copy Link

@silverwind commented on GitHub (Jul 25, 2020):

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).

@silverwind commented on GitHub (Jul 25, 2020): 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).
GiteaMirror commented 2025-11-02 06:27:41 -06:00
Author
Owner
Copy Link

@CL-Jeremy commented on GitHub (Jul 25, 2020):

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.

@CL-Jeremy commented on GitHub (Jul 25, 2020): 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](https://www.microsoft.com/ja-jp/download/details.aspx?id=49116). 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#5520
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?