Bugzilla

(In reply to Jonathan Kew (:jfkthame) from comment #18)
> What `system-ui` maps to may not be a single font or simple list at all -- it may be a collection of fonts for various languages/scripts and/or dependent on the system locale (and just listing all possibilities in a pref doesn't work, because of prioritization), it may be configurable by the user via OS-level preferences/themes/etc. We can't properly reflect things like this via the current font.name-list.* prefs mechanism.
> 
> E.g. on macOS, we should be using [`CTFontCreateUIFontForLanguage`](https://developer.apple.com/documentation/coretext/1511312-ctfontcreateuifontforlanguage?language=objc) to implement `system-ui`, not simply mapping it to ".SFNS Text" or whatever. This will give the appropriate UI font for the language. So for instance we might get the ".Arabic UI Text" font, which is currently inaccessible -- see bug 1605605 -- if that's appropriate for the language. The result might also depend on the requested size (e.g. if there are separate Text and Display optical-size faces). We put some basic support for that into gfxMacPlatformFontList for `-apple-system` when Apple started using a size-dependent system font, a few OS versions ago, but it really was just a crude hack for the one specific case, it's not generalized over languages, multiple-sized faces, etc.

Does Chromium all this perfectly? In other words: Isn't this an issue of "Perfect is the enemy of Good" ?

> (Along with `system-ui`, we should also deal with the other recently-added generics like `ui-serif`, `ui-sans-serif`, `ui-monospace`, etc.; again, this should be based on OS APIs wherever possible rather than font lists that we attempt to maintain.)

`system-ui` is much more urgent for web-compat.

(In reply to Jonathan Kew (:jfkthame) from comment #18)
> What `system-ui` maps to may not be a single font or simple list at all -- it may be a collection of fonts for various languages/scripts and/or dependent on the system locale (and just listing all possibilities in a pref doesn't work, because of prioritization), it may be configurable by the user via OS-level preferences/themes/etc. We can't properly reflect things like this via the current font.name-list.* prefs mechanism.
> 
> E.g. on macOS, we should be using [`CTFontCreateUIFontForLanguage`](https://developer.apple.com/documentation/coretext/1511312-ctfontcreateuifontforlanguage?language=objc) to implement `system-ui`, not simply mapping it to ".SFNS Text" or whatever. This will give the appropriate UI font for the language. So for instance we might get the ".Arabic UI Text" font, which is currently inaccessible -- see bug 1605605 -- if that's appropriate for the language. The result might also depend on the requested size (e.g. if there are separate Text and Display optical-size faces). We put some basic support for that into gfxMacPlatformFontList for `-apple-system` when Apple started using a size-dependent system font, a few OS versions ago, but it really was just a crude hack for the one specific case, it's not generalized over languages, multiple-sized faces, etc.

Does Chromium all this perfectly? In other words: Isn't this an issue of "Perfect is the enemy of Good" ?

> (Along with `system-ui`, we should also deal with the other recently-added generics like `ui-serif`, `ui-sans-serif`, `ui-monospace`, etc.; 

`system-ui` is much more urgent for web-compat.