Does "system-ui" really needed under Windows?

[CaiMiao]

I met this problem when I using Grav, and later I found this is not Grav specific problem at least:

I'm building a Japanese site with lang="ja" being correctly assigned to html tag.
All other font-family overriding entries have been overwrittten with inherit.
And let's assume the final valid css entry for Japanese is :

html:lang(ja), .lang-ja { font-family: -apple-system, system-ui, BlinkMacSystemFont, sans-serif ; }

But when I check my site under Simp. Chinese Windows, it displays like this :

You can see the browser selected a Chinese font as the fallback for system-ui, which is against one of my intended purposes : use lang="ja" to let the renderer determine an existing Japanese font as the final fallback font.

When I remove system-ui, everything works as intended.

Also, I've checked my site using iPad before system-ui removal, it fallbacks to Hiragino Sans without problem, that's why I would say it's a problem under Windows. I don't see system-ui makes any sense for other OS so it might be totally useless or even worse in actual practice.

There are also few articles about deprecating system-ui, I link one of them here fyi.
https://infinnie.github.io/blog/2017/systemui.html

[CaiMiao]

Bootstrap also removed it.
twbs/bootstrap#22377

[CL-Jeremy]

In any case, -apple-system and BlinkMacSystemFont should stay next to each other in a native font stack. Swapping the latter with system-ui would be a quick fix.

As with system-ui, it's used to refer to the OS's native font stack (e. g. that defined by Fontconfig in desktop Linux environments, where it is fully customizable by the user - I use Inter for that and would like to also see sites rendered with Inter, while leaving sans-serif as Liberation Sans or the like, which may be defined differently in browser settings). This feature is intended to be used to render western texts and opportunistically also other code points (cf. MDN), like that with sans-serif, which has its own quirks on different platforms.

Unfortunately, we do not yet live in a world where this standard is well/consistently supported across platforms. Its behavior does vary between browsers, even under Linux, and is mostly useless or counterproductive under Windows (if I recall correctly, the effect in your case corresponds to sans-serif in the user's current system locale). However, I still envision the future of this feature in modern browsers getting consistent for non-Latin scripts. For now, considering the diversity of fonts installed on various Windows machines, I'd rather just specify them individually for each locale - imagine a Windows Vista/7 machine with Yu Gothic supplement pack (most commonly comes bundled with Microsoft Office) installed, you'd rather use that instead of Meiryo for Japanese, as the former has become standard since Windows 8.1, and retain the latter for fallback, along with MS Gothic.

An example of my own CJK-proof native-ish font stack (for Fomantic UI) could be found here (note: upstream has not yet fixed their bugs introduced by several maintenance commits, while the base stylesheets have since been renovated with modern variable-based native CSS instead of Less mixins).

Last but not least, if you insist on the removal of system-ui due to the chaotic situation it creates (and the cumbersome workarounds for those affected by this issue, of whom the majority would most probably not make use of this feature at all), I'd happily support your proposal.

Edit: it seems Bootstrap has lifted system-ui to the first place in the stack. Notes on this may be found here.

Edit 2: Damn, just tested under zh-CN locale. system-ui breaks entirely. I totally forgot the fact my test system was in German when I was developing the above font stack. In this case it's really harmful to use this until major browsers decide to ditch their current behavior.

[CL-Jeremy]

10 days of hard work to bring out this solution: go-gitea/gitea#14575.

https://gist.github.com/CL-Jeremy/efd1351858c4feb894d6aee0bea448e0 (with 600 as boldface, as requested by original project)

TL;DR: this solution creates custom font faces based on stacks of selected local fonts to deliver good results on various platforms. For Windows, it now hard-codes "Segoe UI" before system-ui to achieve optimal results.

The proposed font stack:

html {
  font-family: -apple-system, "Segoe UI", system-ui, "Roboto", "Helvetica Neue", "Arial", "Noto Sans", "Liberation Sans", sans-serif;
}

html:lang(<locale>), [lang="<locale>"] {
  font-family: system-emoji, system-ui-<locale>, -apple-system, "Segoe UI", system-ui, "Roboto", "Helvetica Neue", "Arial", "Noto Sans", "Liberation Sans", sans-serif;
}

@font-face {
  font-family: system-emoji;
  src: local("Apple Color Emoji"), local("Segoe UI Emoji"), local("Noto Color Emoji"), local("Twemoji Mozilla");
  unicode-range: U+2310-329F, U+FE0?, U+1F000-1FAFF;
}

@font-face {
  font-family: system-ui-<locale>;
  src: <source1>[, <source2>, ...];
  unicode-range: <unicode-range>#;
}

Note the special treatment for emojis, as they share certain code ranges with that of various JIS symbols adopted into Unicode and later repurposed as colored emojis.

[kurtextrem]

I did not test too much, but why not also include 'Segoe UI Symbol'?

[CL-Jeremy]

I did not test too much, but why not also include 'Segoe UI Symbol'?

As noted above, by then I would like to leave that to the monochrome font stack and prefer those symbols from the localized font. Extensive tests have confirmed it being used as a last resort at sans-serif, which is exactly as expected (e. g. Chromium defaults to Segoe UI Symbolson Windows 7, while Firefox ships Twemoji Mozilla and displays Twitter-style emojis).

[SamuelMiller]

@font-face {
  font-family: system-ui-<locale>;
  src: <source1>[, <source2>, ...];
  unicode-range: <unicode-range>#;
}

What does the above do? Where are the variables, source 1 and source 2, etc, defined"?

[CL-Jeremy]

@font-face {
  font-family: system-ui-<locale>;
  src: <source1>[, <source2>, ...];
  unicode-range: <unicode-range>#;
}

What does the above do? Where are the variables, source 1 and source 2, etc, defined"?

Those aren't variables, they are just placeholders (typically written between angle brackets) for the actual localized font stacks. For Japanese, that would include Hiragino Sans, Yu Gothic, Meiryo, MS Gothic, etc.

Note this approach with Unicode ranges has long been deprecated in favor of overriding with CSS variables, as long as the targeted platforms are modern enough to support that feature. Granted, the code I posted was more of a proof of concept than anything else. It's best to keep everything as simple as possible - like just defining everything separately for each language if no more than a handful of languages are needed. The need for system-ui is, of course, still debatable, but I'm sticking with my original opinion.