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

[AmeliaBR]

What would be the authoring use case for this? When would you use system-ui-serif instead of serif?

The whole purpose of the generic font keywords is that the results are suited to the system & the user choices. If a new version of Safari wants to update which fonts the generic keywords map to by default, go right ahead. But I don't see a reason to keep serif and monospace as user-customizable fonts, but then offer authors a way to ignore the user preferences & get the system defaults instead.

The fact that these fonts don't have an exposed family name is an implementation detail on MacOS/iOS. If there are technical reasons for that, but you still want them available to web content, I think it's appropriate to continue to use prefixed keywords for them.

(I personally don't understand branding logic behind the "don't let people use them in documents, but do let websites use them" argument, but 🤷‍♀ …lawyers. )

I don't know if Windows has any analogues with Segoe UI.

Segoe is a super-family on Windows 10, but it doesn't have monospaced or serif version: it has handwriting versions. Segoe Print is the modern alternative to Comic Sans.

While we're on the topic: Segoe UI looks absolutely horrible when rendered without ClearType hinting (at least, I think that's why it sometimes looks awful). I really hate that we're encouraging developers to use system-ui in order to get San Francisco on Apple devices, instead of thinking carefully about their font stack in a cross-browser way.

[Crissov]

How are New York, SF Mono and SF Rounded used in Appleʼs UIs? Are they the only fonts used in the UIs? Are they the only ones hidden for corporate identity purposes? Are the latter two fonts proper parts of the SF / San Francisco (super) family?

CSS generic font keywords were never well designed (especially i18n-wise), but (at least without further information) I donʼt think this proposal improves anything about that.

[litherum]

When would you use system-ui-serif instead of serif?

When you wanted New York instead of Times. Times has been baked into the Web Platform for so long, we effectively can’t change the serif - Times mapping.

We also don’t want to automatically opt a bunch of websites into using New York because it is intended to be used selectively in new content. It isn’t a document font that is supposed to be used everywhere.

[AmeliaBR]

Times has been baked into the Web Platform for so long, we effectively can’t change the serif - Times mapping.

There is nothing baked-in about using Times and Arial for serif and sans-serif. Other browsers let the end user change the mappings. I use Georgia and Tahoma. For monospace, even the default mapping varies by browser/OS.

Any website that is using the generic font family keywords is accepting that the appearance will vary by browser & OS & user preferences. If an author really wanted Times, it's easy for them to say so.

That said, if Apple for branding purposes doesn't want the new fonts to ever be the default font used in web content, that's fine. As I said before, this is one case where I think it's fine to keep using CSS prefixes, since this (fonts that you can't access by a normal name) is a feature that has no equivalent in other OS.

[othermaciej]

@AmeliaBR I think your objection has three core elements. I'll try to restate it, and please let me know if I got anything wrong. I'll use the system-ui-serif example, but this could apply to all of these:

1. Objection: Introducing system-ui-serif to mean the system serif font (where that is defined and is not Times) is unnecessary, because the browser could just change the meaning of serif to be, say "New York" on Apple platforms.

2. Objection: system-ui-serif is redundant with serif, because they don't have meaningfully distinct use cases for authors.

3. Objection: Introducing new symbolic font names is sad, because the old names like serif allow customization in many browsers, but system-ui and its possible future friends do not.

Let me know if I missed a key part of your objections.

Now, addressing these in turn:

1. Response: In practice, browsers can't change the default meaning of serif. Nearly all browsers map it to Times by default, and some web content has come to depend on this. The default Times mapping is necessary for web compatibility, at the very least for desktop web content. It's true that the user could customize it, and some website may subvert author intent or outright break if the user does that.

2. Response: system-ui-serif has a distinct use case from serif for authors. It means: give me a serif font that matches the system UI appearance, because I'd like this web content to blend in with the system look. On the other hand, serif, depending on author expertise, means one of "give me a serif font, I don't care which" or "give me Times, that's what I see on my system so that's what users will get". Neither of these is the same as "match the system standard serif font". In reality, the alternative to system-ui-serif for its intended use case is a long fallback list of the known system serif fonts, carefully ordered to avoid the wrong one appearing on the wrong system.

3. Response: Customizability can be valuable. On some systems, the system fonts are customizable. It would make sense for the system-ui family of symbolic font names to follow system customization, rather than browser-only customization. But, in any case, authors already have access to requesting specific fonts by name, in such cases, the font is not customizable at all. In the absence of system-ui-serif and the like, websites would have to specify fallback lists of exact fonts to get the same effect. And that isn't customizable even in theory, or at the system level.

I'll add that none of this depends on the fact that the fonts aren't normally accessible by name. That makes the use case more urgent for some, but the use case is not really satisfied by specifying exact font names.

[AmeliaBR]

Thank you for the detailed response, @othermaciej. Yes, you summarized my concerns fairly. But I remain unconvinced.

I still don't see an authoring use case for "match the system standard serif font" because most systems don't have standard serif (or rounded or monospace) fonts. @litherum's proposal states that there is an authoring demand to access these particular new fonts on Apple devices. But that's different from the argument for system-ui, which was that many major websites were crafting font stacks designed to match the standard system font for each OS.

I'd also be curious to see any evidence of web incompatibility for changing the Times/Arial defaults — just because something would change doesn't mean it would be incompatible. And if changing the generics is incompatible for a given website, then that website is probably already broken for many users. If there is a web compability reason to map the generic font names to specific fonts, we should put that in the spec.

[litherum]

Evidence of WebGPU incompatibility

In the WebKit source, we spoof the metrics of Times to match Windows’s metrics. We did this for web compat. Asking for Times by name is relatively rare compared to asking for serif and expecting Times.

Another piece of this issue that I forgot to include in the original post is the fact that the macOS and iOS APIs that access these fonts do it by token, not by name. Nowhere in source code do you ever say “New York” to get New York in a native app. Instead, you ask for “the serif design of the system font.” The mapping of system-ui-serif -> New York may change in the future. So, asking for New York by name isn’t expected to be stable over time.

[othermaciej]

I still don't see an authoring use case for "match the system standard serif font" because most systems don't have standard serif (or rounded or monospace) fonts.

Rounded appears unique to Apple platforms. But system serif and monospace system fonts seem to exist on at least Android, iOS/iPadOS and macOS. According to statcounter, these operating systems account for 59.56% of global browsing use share. That seems like a significant enough share that it would be valuable

So far, we've not exposed these fonts to the web at all, and we'd be very reluctant to expose them to the open web as symbolic names with a -apple or -webkit prefix. That would leave other platforms out in the cold (either with existing serif/mono system fonts, or if they add them in the future) and would lead to authoring of Apple-platform-specific CSS, which we would prefer not to encourage further. Right now they are only exposed in specific native apps that opt in. We'd prefer websites and web apps to have access to this functionality as well, if a suitable syntax is accepted as standards-track

[Crissov]

How are existing font keywords caption, icon, menu, message-box, small-caption, status-bar not suitable to access these fonts?

System fonts can only be set as a whole; that is, the font family, size, weight, style, etc. are all set at the same time. These values can then be altered individually if desired.

[kojiishi]

I support the proposal.

IIUC @AmeliaBR's points apply not only to this proposal but also to the original system-ui. At that point, we understood two different web author's voices:

1. Wanting to use user's favorite generic families.
2. Wanting to use the same fonts as other native applications.

We resolved generic families to serve for 1, while system-ui to serve for 2. When certain number of web authors wanted to create app-looking pages, adding system-ui had a clear benefits over hard-coding system font names of all major operating systems in their CSS.

Because the motivation for system-ui is to give the same capability as applications to the web, when applications got new capabilities, I think it's natural and necessary to allow the web to use them.

[emilio]

Aren't system font's the mechanism for (2)? What's the status of that in other browsers?

In Gecko, you can do font: message-box or font: caption for example to get a font that looks like your system's. It seems like Blink and WebKit also support these.

Not particularly opposed to the proposal, but want to understand how it compares to them. These look more like system fonts than font family names per se. But I guess since they don't convey the size and such that a system font would have it's ok to make them just generic family names?

[litherum]

font: message-box or font: caption for example

Yep, these get you San Francisco in WebKit on macOS and iOS. None of the existing font or font-family keywords get you New York, SF Mono, or SF Rounded. And, because these fonts aren't exposed to the system as regular fonts available in pickers, there is currently nothing you can type in CSS that will give you access to them. system-ui-serif, system-ui-monospaced, and system-ui-rounded would be the only way to access these fonts.

[othermaciej]

How are existing font keywords caption, icon, menu, message-box, small-caption, status-bar not suitable to access these fonts?

System fonts can only be set as a whole; that is, the font family, size, weight, style, etc. are all set at the same time. These values can then be altered individually if desired.

Two reasons:

1. None of those necessarily correspond to "the system serif font" or "the system monospace font". On operating systems I am familiar with, none of those are set in serif or monospace.

2. The system serif and monospace fonts (just like the regular system font) do not necessarily have an implied size, weight or style; they are used in different sizes, weights or styles in different contexts.

This particular set of keywords is also somewhat old-fashioned in that it maps to desktop-style mouse plus overlapping window UIs, but not to modern mobile-style touch-based UIs.

[othermaciej]

But I guess since they don't convey the size and such that a system font would have it's ok to make them just generic family names?

This is exactly the reason these are proposed as symbolic family names instead of special font keywords (as with system-ui).

[kojiishi]

Aren't system font's the mechanism for (2)?

Yes, that's s what I meant.

What's the status of that in other browser?

Blink added it a few years ago given web authors' requests, and app-looking sites (eg github) started using it.