1226042 - add support for the new 'system-ui' generic font family

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, enhancement)

Description

[John Daggett (:jtd)]

The CSSWG resolved today to add a new generic font family name, 'system-ui', that maps to the default system UI font. 

https://logs.csswg.org/irc.w3.org/css/2015-11-18/#e621666

This will be specified in the CSS4 Fonts spec.

Three components to this:

- parsing and handling of the new generic in CSS code
- platform-specific lookup, lang dependent
- appropriate handling of things like fallback

The last item is probably the trickiest. Under OSX, the "system" font is always a Latin font, e.g. San Francisco or Helvetica Neue, but it's linked to a specific set of fallback font families, so that the Latin font is used for Latin glyphs and a system Japanese font is used for Japanese. Need to research what happens precisely under Windows (i.e. always Meiryo UI or only for CJK characters?).

Comment 1

[yisibl]

Chrome: Intent to Implement and Ship: The “system-ui” generic font family

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/hvN9YVvIb5c

Comment 2

[j.j.]

Chrome shipped font-family:system-ui in version 56 some month ago.
Safari fixed in 2017-02: https://bugs.webkit.org/show_bug.cgi?id=151493

Chrome status entry says Firefox shipped also ...
https://www.chromestatus.com/feature/5640395337760768

Comment 3

[Cameron McCormack (:heycam)]

(In reply to j.j. from comment #2)
> Chrome status entry says Firefox shipped also ...
> https://www.chromestatus.com/feature/5640395337760768

That seems wrong.  I'll email Koji.

Comment 4

[Florens Verschelde :fvsch]

Would be interested in this for DevTools. We use Firefox-only things like font:message-box, which has the downside of a) resetting the font-size and b) resetting it to different values depending on the platform.

(Some tools such as debugger-html and perf-html are also used outside of Firefox, so a standard solution would be best.)

Comment 5

[Jonathan Kingston [:jkt] he/him]

Should this block the result of https://github.com/w3c/csswg-drafts/issues/1586 it would be nice to not expose to the webside what the chosen system font is.

Comment 6

[Thomas Wisniewski [:twisniewski]]

Note that coda.io uses this on their page, which causes Firefox to select Arial on Windows 10 where Chrome selects Segoe UI. This doesn't seem to break anything in their layout, but it's still an interop difference worth noting.

Comment 7

[Andy Grover [:grover]]

Is this implemented and done? Looking at twitter.com in the inspector, it looks like the font chosen is "system-ui" in FF 70. (Only seems to be used if I'm logged in to twitter and using the new UI.)

Comment 8

[Andy Grover [:grover]]

Attachment: Screenshot from 2019-10-29 13-18-47.png

shows system-ui as underlined

Comment 9

[Jonathan Kingston [:jkt] he/him]

:grover I have seen that before, I think this is a devtools issue with how they select what is underlined for native fonts.

Comment 10

[andrej]

The implementation is definitely buggy. The selected font is Cantarell. I'm on Linux, KDE, with Noto Sans as default font. I don't even know how Cantarell ended up on my system. Could be through a Lutris/Wine package.

Chromium defaults to Noto as expected. How FF sniffs out Cantarell is beyond me. I tried grep-ing through my ~/.config and got nothing of relevance. Rather than system-ui resolving incorrectly, I'd prefer it failed and skipped to the second entry in the font stack.

Tl;dr this resolves into Cantarell being used which is not my configured system font:
font-family: system-ui, "Noto Sans", "Helvetica Neue", Arial, sans-serif;

FF: 70.0.1
Linux/KDE all pretty much latest because it's Arch.

Comment 11

[Jonathan Kew [:jfkthame]]

(In reply to Jonathan Kingston [:jkt] from comment #9)

:grover I have seen that before, I think this is a devtools issue with how they select what is underlined for native fonts.

Right, that's bug 1545745. Firefox does not currently support system-ui at all.

Comment 12

[ebrahim]

While implementing this be ware to retrieve 'system-ui' per language/script not once for entire scripts, for example on macOS San Francisco is the Latin font for system-ui but .Arabic UI Text is for Arabic scripts, Safari is OK on this regard, filed the issue against Chrome's current system-ui support https://crbug.com/1036695 so, just make sure data:text/html;charset=utf8,<div lang="ar" style="font-family: system-ui, arial; font-size: 300%;">%D8%B3%D9%84%D8%A7%D9%85! renders exactly similar with Safari if a correct implementation is considered.

Comment 13

[Daniel M. Capella]

(In reply to andrej from comment #10)

The implementation is definitely buggy. The selected font is Cantarell. I'm on Linux, KDE, with Noto Sans as default font. I don't even know how Cantarell ended up on my system. Could be through a Lutris/Wine package.

Chromium defaults to Noto as expected. How FF sniffs out Cantarell is beyond me. I tried grep-ing through my ~/.config and got nothing of relevance. Rather than system-ui resolving incorrectly, I'd prefer it failed and skipped to the second entry in the font stack.

Tl;dr this resolves into Cantarell being used which is not my configured system font:
font-family: system-ui, "Noto Sans", "Helvetica Neue", Arial, sans-serif;

FF: 70.0.1
Linux/KDE all pretty much latest because it's Arch.

fontconfig has supported system-ui since 2.13.91:
https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/dba84600e1485000f358d8259b92721cf7066034

Comment 14

[Jonathan Kew [:jfkthame]]

Firefox doesn't support system-ui. (That's why this bug is open.)

If you run fc-match :family=system-ui in a terminal, what does that return? From what I see in https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/dba84600e1485000f358d8259b92721cf7066034#189a3e6149b0632ddea0bc7bd3cb46492675e52e, it looks like this could well be resolving to Cantarell if it's installed.

Comment 15

[L]

I believe this should be given priority, as I'm seeing more and more sites default to system fonts and not web fonts.
Basically anyone who isn't using web fonts or custom fonts wants to use system-ui.

Leaving aside Firefox, all major browsers make correct use of the feature. Firefox needs to be verbose:

font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Helvetica Neue", Arial, sans-serif, "Apple Color Emoji";
vs
font-family: system-ui;

Any plans for this? Since the bug has been open for 6 years now.

Comment 16

[Emilio Cobos Álvarez (:emilio)]

There's no concrete plan for this. I guess I can keep it on my list of things to do, now that I have some free time coming up.

The CSS bits for this are not hard to implement (it's a matter of adding a SystemUi variant here, and that'd take care of all the parsing / serialization / etc).

I'm not too familiar with the font selection bits, but I suspect that's a matter of making sure we look at the right prefs and add a bunch of per-platform values like we do for the emoji font here for example...

Jonathan does that sound right? Or am I missing other complications?

Comment 17

[Emilio Cobos Álvarez (:emilio)]

(I guess I can take this, assuming the above is true. We should do a bit of research on whether the font resolves to different things based on the language on other browsers or what not, but that should not be too hard either)

Comment 18

[Jonathan Kew [:jfkthame]]

We really shouldn't be implementing this by adding more font-list prefs that we then need to maintain as platforms evolve and change what they ship. That's a maintenance headache we can do without.

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

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

Comment 19

[j.j.]

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

Comment 20

[Vadim Makeev]

Here’s a code sample from Google I/O Workshop (video, codelab)

body {
  font-family: system-ui, sans-serif;
}

Since system-ui value is supported by Chrome and Safari, there’s no reason for most of the people to bother with a huge list of system fallback fonts mentioned in comments above. And because of that Firefox users get some old-school sans-serif fallback. In macOS case it’s Helvetica instead if San Francisco, but it could be much worse.

Comment 21

[aweb33]

Is there any reason to delay this feature? The only reason I cannot use system-ui is because of Firefox, and for seemingly no reason Firefox doesn't support this feature whereas all other browers support it.

Comment 22

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1226042 - Enable system-ui font-family. r=jfkthame

Making the macOS font selection language-dependent is a nice
improvement (which we should probably make to all system fonts in
general), but I don't think it should block this.

system-ui behaves like -apple-system right now, which a bunch of pages
use instead. So I think this is a strict improvement even on macOS.

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0d463dd5a5cc
Enable system-ui font-family. r=jfkthame

Comment 24

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/0d463dd5a5cc

Comment 25

[Rachel Andrew]

Added to BCD and release notes https://github.com/mdn/content/issues/7751