[css-fonts] system-ui-serif, system-ui-monospace, and system-ui-rounded

[litherum]

Hi!

This year, Apple has released 3 fonts in macOS and iOS. Here are what they look like:

New York:

SF Mono

SF Rounded

We've gotten requests to use these three fonts on the Web. However, we don't want to treat these fonts just like any other font. On macOS and iOS, these fonts are only available by running special AppKit/UIKit functions, and don't appear in font enumerations. This choice is intentional, as these fonts are not intended to be document fonts for regular content. Instead, they represent the identity of the platforms themselves.

Because of the requests, we'd like to propose adding these fonts to the CSS Fonts spec as siblings to system-ui, and including some explanatory text in the spec about the difference between these fonts and any other installed fonts on the system.

Android has Droid Serif and Droid Sans Mono which would map to system-ui-serif and system-ui-monospaced. I don't know if Windows has any analogues with Segoe UI.

We've recently implemented support for these in Safari behind an SPI flag, off by default. This is an SPI, not an experimental feature, so Safari users can't even enable the fonts if they wanted to just yet.

[Crissov]

Whatʼs the i18n story on the suggested values, especially re East (CJKV), South (Brahmic) and South-West (Semitic) Asian scripts? Some are always monospaced, some are always cursive, some are always rounded, some are always sans-serif …

Does each keyword resolve to different actual fonts depending on the characters?

[AmeliaBR]

@Crissov The spec already says that generic fonts can be composite fonts, combining different families for different languages/Unicode ranges. That would presumably apply to these new values, too.

[Crissov]

Indeed, but this does not quite answer my first question.

Does ui-monospaced always exist for CJKV? Does ui-rounded always exist for, say, Malayalam and Telugu?

[AmeliaBR]

Does ui-monospaced always exist for CJKV? Does ui-rounded always exist for, say, Malayalam and Telugu?

Oh, I see. Yes, that would be different from the regular generic fonts, which are defined to always exist for all characters. I believe the agreement was that these keywords would fall back like regular font families, which means that if they only exist for certain Unicode ranges on the platform, then non-matching characters would fall back to the next value on the font stack.

[Crissov]

No ui-sans-serif, though? system-ui may have serifs.

[AmeliaBR]

No ui-sans-serif, though? system-ui may have serifs.

Agreed. We shouldn't assume which style system-ui uses. Fashions change & it may not always be a sans. Authors should be able to specifically ask for ui-sans-serif as much as asking for ui-serif.

[litherum]

Please open a new issue for it :)

[AmeliaBR]

Please open a new issue for it :)

Done: #4468 ([css-fonts] Add a ui-sans-serif keyword to go with ui-serif)

I also added [css-fonts] Inconsistency between monospace and ui-monospaced #4469 after reviewing the edits.

[litherum]

@fantasai

Note: CSSWG also recommended that fonts exposed via these keywords also be exposed by some normal font names, so that people don't start to use the keywords as a proxy for certain fonts (and then start to depend on that behavior).

Note added in https://github.com/w3c/csswg-drafts/commit/7f8d8186a7e4a23898cd27b4bdc50bbc0159cc20

[fantasai]

@litherum I don't think that's quite the intention. Firstly, we have to make a clear distinction between generic family keywords and font names. Secondly, the concern in the note wasn't so much to control the system fallback in a particular way as to explicitly select certain desired fonts when they are available available rather than assuming a certain generic keyword always returns that desired font. Maybe something like

Note: User agents / operating systems are encouraged to also expose these standard font families by actual font-specific <family-name> values, in addition to the keywords given here, so that authors can request those specific fonts without making an assumption about a standard font family keyword mapping to a specific font.

I think you also need to clarify that these new values are keywords, like <generic-family>, not strings that can sometimes be left unquoted, like <family-name>. It might be worth giving them their own <system-family> value type.

[AmeliaBR]

I think you also need to clarify that these new values are keywords, like <generic-family>,

If the changes suggested in #4442 are accepted, we can just include these keywords in <generic-family> and not worry about repeating the syntax details.

For the note:

For authors, we want to emphasize that using these keywords will get different results on each platform (though hopefully consistent within an OS), and the mappings may change over time. If they want specific fonts, they need to use specific font-family names. I think Myles' note covers that.

For user agents, the "encouragement" is to give authors that choice, by making fonts available either by keyword or by name.

It might be helpful to therefore break this into two separate notes:

Note: These standard font families are expected to exist on different platforms, but be backed by different fonts. The mappings may also change over time, as the operating system fonts change. Authors who wish to use specific fonts should specify them by font-family name, rather than with these keywords. The keywords are specifically intended for authors who wish their design to always match the current operating system typography.

Note: To make it possible for authors to specify fonts by font-family name instead of with these keywords (when that is their design intent), user agents are encouraged to expose the system font families by other, platform-specific, font-family names, in addition to the keywords given here.

[ExE-Boss]

We should change monospaced to monospace in the issue title, to avoid #4469 happening a second time.

[svgeesus]

I'm seeing a Needs Edits label but am unclear on exactly what edit is outstanding.

[svgeesus]

Closing as these changes have been made, see for example https://drafts.csswg.org/css-fonts-4/#ui-rounded-def