-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
Comments
Could we do this now that 1.12 is released? |
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). |
- 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
- 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>
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 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. |
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?
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. |
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.
Yes
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 |
I'm certainly not against trying to utilize system's |
@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 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. |
I guess we could certainly tweak the font stack to prefer Ubuntu's default font over Segeo UI. |
Apart from that, I believe the semantics behind And the quirks don’t end there. On macOS, all browsers, with the sole exception of Safari, matches 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! |
I wonder if it'd be possible to remove all the explicit fonts and user either |
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).
Again, the semantics are different. What this means is, whenever And even with 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. |
- 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>
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:
font-display: block
and default behaviour in most browsers)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:
GitLab has:
The text was updated successfully, but these errors were encountered: