Closed Bug 1226042 Opened 9 years ago Closed 3 years ago

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

Categories

(Core :: CSS Parsing and Computation, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
92 Branch
Tracking Status
firefox45 --- wontfix
firefox59 --- wontfix
firefox92 --- fixed

People

(Reporter: jtd, Assigned: emilio)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

(Keywords: dev-doc-complete, parity-chrome, parity-safari)

Attachments

(2 files)

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?).
Chrome: Intent to Implement and Ship: The “system-ui” generic font family

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/hvN9YVvIb5c
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
Keywords: dev-doc-needed
(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.
Blocks: 1461302
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.)

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.

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.

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

shows system-ui as underlined

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

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.

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

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.

See Also: → 1605605
Assignee: jd.bugzilla → nobody

(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

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.

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.

Flags: needinfo?(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?

Flags: needinfo?(emilio) → needinfo?(jfkthame)

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

Assignee: nobody → emilio
Flags: needinfo?(emilio)

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

Flags: needinfo?(jfkthame)

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

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.

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.

Type: defect → enhancement
Depends on: 1720453
Blocks: 1715898
Depends on: 1720710
Depends on: 1722009
Blocks: 1722488

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.

Flags: needinfo?(emilio)
Blocks: 1723552
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0d463dd5a5cc
Enable system-ui font-family. r=jfkthame
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 92 Branch

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

Regressions: 1724710
Regressions: 1724907
Regressions: 1730098
See Also: → 1741448
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: