Csswg-drafts: [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.

[Crissov]

If the use case is to adaptively mimic the OS look, I expect the OS to actually use these fonts for some part of its GUI. This would not be monospace but console or terminal, not serif but body or document, not rounded but caption or whatever.

Apple should probably be proposing font keywords to map to their HIGʼs Dynamic Font Variants, if the existing ones cited earlier do not suffice:

iOS, watchOS, tvOS

• Large Title
• Title 1
• Title 2
• Title 3
• Headline
• Body
• Callout
• Subhead
• Footnote
• Caption 1
• Caption 2

macOS

• Control Content
• Label
• Menu
• Menu Bar
• Message
• Palette
• Title
• Tool Tips
• Document Text (User)
• Monospaced Document Text (User Fixed Pitch)
• Bold System Font
• System Font

I did not find _New York_ being documented for any of that (yet), though.

Windows

• Header
• Subheader
• Title
• Subtitle
• Base
• Body
• Caption

Furthermore, it is perfectly fine to map the the fonts in question to font-family keywords like serif, monospace and fantasy. If any website out there “fails” because its authors expected serif to mean _Times [New Roman]_, it absolutely needs to “fail”. However, I cannot imagine how anyone would consider a slightly different font being used as “failing”.

[kojiishi]

If the use case is to adaptively mimic the OS look, ...

This is probably the most confusing part, but as I read more feedback and articles about system-ui, authors do not want to mimic the OS look. Before, I thought they do, but I'm revising my understanding now.

The article Using UI System Fonts In Web Design: A Quick Practical Guide explains that the goal is:

1. Feel more like an app.
2. To draw clear lines between the content and user interface.
3. To use modern, beautiful fonts with zero latency.

and the emphasis on the item 3. It says using system UI fonts suffice this goal, namely Roboto, San Francisco, and Segoe.

Then this github article explains that, it turns out that using the system font of the platform does not suffice these goals on older and/or CJK versions of Windows. They prefer Segoe or Arial over decades-old Tahoma or poorly rendered Chinese fonts, and that stopped using system-ui. And this isn't only github saying.

In my new understanding, authors want modern, beautiful UI fonts, rather than the actual system UI fonts of the platform. I think it's more similar to a UI version of sans-serif generic font family rather than a different version of font: menu keyword. Authors want to use serif or sans-serif for UI, rather than exactly the same font family, style, and size of caption or status-bar of the platform.

I'm looking into updating Blink's system-ui to reflect the feedback, and this proposal looks like a good extension to it.

[Crissov]

Thanks Koji, I think I understand the actual issue better now.

My problem then is with the ui- part of the proposed keywords, because apparently the fonts in question are not part of the system user interface (i.e. UI) at all. They are part of the OS vendorʼs flagship font super family, which is an essential and important part of their corporate design and identity. Seriously, please just drop it from the proposed keywords.

Hence, serif would mean _give me some generic letters with serifs that look somewhat like everywhere else_ while system-serif or perhaps env(serif-font, serif) would mean _give me some iconic letters with serifs that represent the look of the system/environment_.

[othermaciej]

For Apple, at least the serif (New York) and monospace (SF Mono) variants are used in parts of what we consider to be system UI, just not very often compared to sans. The serif variant is used when significant sections of published text are to be presented in a readable format. The mono variant is used when displaying code, a command-line terminal, or things of that nature.

(I am not aware offhand of a place that uses the rounded variant, but @litherum might know.)

[litherum]

The wallet app on iOS uses it as part of the UI:

And it’s used throughout the watchOS interface.

[jensimmons]

I agree with Myles on this.

The usecase for system-ui, system-ui-serif, system-ui-monospaced, etc is different than the usecase for serif or monospaced.

By using a system-ui-* font, an Author is asking the browser to pick fonts that match the Operating System, knowing that if/when the operating system changes it's fonts, their website/app will be changed as well. It's stating an intention to blend into the OS.

By using a generic serif- or monospaced, and Author is saying, give me whatever is available in this browser, I can't really care what it is, just give me something that works in the serif/sans-serif/monospaced bucket of fonts. This is used most commonly as a fallback. Authors state: I want this fancy webfont I'm providing, or if that didn't download then please use this particular built-in-the-browser font, but if you don't have that font, then please at least pick some sans-serif font. In that usecase Authors are _not_ expecting their project to suddenly then match the OS. In fact ,it's likely they do not want their project to suddenly match the OS' typography.

[bradkemper]

I also agree with Myles and Jen, so far. But I would like guidance on what to author for fallback to cover Android, Windows, etc. Would there be system-ui-sans on some OS’s? Would I have font-family: system-ui-rounded, “Helvetia Rounded”, system-ui-sans, system-ui, san-serif;?

[litherum]

system-ui-rounded might map to Segoe Script or Segoe Print on Windows.

[svgeesus]

@litherum wrote:

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.

A little odd, but understood. But then "We've gotten requests to use these three fonts on the Web" should surely be met with "No, we don't want you to do that so we hid them" not "here is the CSS to do just that".

On a more detailed note, it is clear what happens with a browser that does not understand the new generic name. However, what happens if the browser _does_ understand, say, system-ui-rounded but that doesn't translate to a suitable font on the platform. Should it

a) be skipped over, to the next font in the list, or
b) fall back to system-ui which is kind of the super-family?

[css-meeting-bot]

The CSS Working Group just discussed system-ui-serif, system-ui-monospaced, and system-ui-rounded.

The full IRC log of that discussion

<dael> Topic: system-ui-serif, system-ui-monospaced, and system-ui-rounded

<dael> github: https://github.com/w3c/csswg-drafts/issues/4107

<dael> myles: In latest version of macOS and iOS we've added 3 new fonts. You can see them in this issue

<dael> myles: These are new fonts but aren't like regular fonts. Don't show in font pickers and you can't get them in native apps by name. THere's a new codepath that causes these fonts and that's intentional

<dael> myles: These fonts are designed to match design language of OS. Not intended to be used in a document font. Not supposed to use in an essay.

<dael> myles: THere's nothing you can type in CSS to use these fonts which is unfortunate. Have heard requests to use them.

<dael> myles: Proposal is that b/c these fonts designed to match the system they should be added as sibs to system UI generic font family

<dael> myles: Might ask why not use existing generic font family. Reason is mechnically we can't b/c serif face is mapped to Times and if we change that we break the web. Need to be a new opt-in thing.

<dael> myles: New fonts shouldn't be used as a document typeface

<chris> q+ to ask why making these available on web if by design, they are not to be used in documents

<florian> q-

<dael> myles: What do you guys think about adding a way to get to these fonts?

<dael> Rossen_: Curious if another way is have them in static variables introducing for other system things like scrollbar thickness

<dbaron> I'm curious about whether we want the 'rounded' name in CSS, rather than our existing 'sans-serif' which it seems similar to...

<dael> myles: Mechanically fine. Confusing to authors b/c there's a way to ask for font-family from system.

<dael> chris: Why do this if whole point is not to use in word documents if you give css they can do specifically that. I'm curious why you hide in one hand and available on the other hand

<dael> leaverou: seems this is adding a very specific language feature that's OS specific. I don't htink we generally do that.

<dael> myles: One at a time. Chris question: This is interesting. On our platform there's a tension between system fonts and not. There isn't that on the web. Only distinction is they're font families that start with 'system-ui'. Can't stop people, but it's more important to give access then the design restrictions.

<AmeliaBR> dbaron, rounded isn't the same as sans; it's usually a sans font, but with rounded ends of strokes. Myles' naming system assumes that the default system-ui is sans-serif, so they haven't included a system-ui-sans.

<dael> myles: Trying to indicate these are system fonts by manner exposed to CSS and hoping that's good enough people will do the right thing. Things are either present or not in CSS 3.

<dael> chris: If an impl supports these keywords by on platform they don't map would it fallback to next font or system-ui? I'd like to propose clarify that case

<dael> myles: I see both arguments. Willing to go with WG desires

<chris> I can see merits in both options also. I just want it to be clear.

<dael> AmeliaBR: For the existing generic fonts I think we still require UAs to have something match those. I think we have exceptions for emoji generic font. If we have generic font names that are allowed to not match that would be a new way of talking about what a generic font is

<dael> AmeliaBR: One benefit of the suggestion to use environment variables is they then allow authors to decide what the fallback would be. Would have to think carefully of how that works with the way env/ variables work with replacing tokens and how that works with font-family fallback. Don't want to invalidate entire exporession

<dael> AmeliaBR: Fallbacks worth thinking about b/c don't have logical eq in other systems

<dael> Rossen_: Need to think through use cases.

<dael> Rossen_: We're a minute over. myles I don't think we'll get to resolve. Anything else you want to add before we end the call? Of course there's a call for people to read proposal and comment on the issue.

<dael> myles: It sounds like there's more to discuss so I hope this comes up on a future call

<dael> Rossen_: Will put it on next weeks call as well. Hopefully people can also discuss on github

[litherum]

@svgeesus Given the design usage of these fonts, it makes more sense that they would fallback to system-ui than to be ignored in the font-family list. Therefore, a browser which supports these fonts but is running on a platform where they aren't relevant, should consider them synonyms for system-ui.

[AmeliaBR]

Would it be helpful to consider this as a functional notation?

Like system-ui(rounded) to say "use a system UI font, rounded if you have one, otherwise the default system UI font", or system-ui(serif, monospace) to mean "use a system UI font, serif if you have it, otherwise monospace (otherwise the default). The function as a whole would be guaranteed to match a System UI font, but the style keywords inside create their own internal fallback list.

[litherum]

system-ui(serif, monospace) seems like overengineering the problem. This is exactly what the font family cascade is supposed to solve. It's true that, if we enforce the behavior suggested in https://github.com/w3c/csswg-drafts/issues/4107#issuecomment-524565243, it will be impossible to fall back from serif to rounded, but I can't think of a case in UI design where that's desirable.

As for syntax, I think there are a few contestants:

• system-ui-rounded: Familiar to authors, yet possibly causing compatibility problems if anyone ever makes a real font with this exact name for some reason. (Note: This concern is relevant to every generic font family name.)
• system-ui(rounded): Simple, yet possibly confusing because font family names are strings in every other context
• env(system-ui-rounded): Conceptually pure, but exposes the platform-specific font name to the Web, if this environment variable was used in another context. E.g. content: env(system-ui-rounded).

[Crissov]

Itʼs up to [css-env] to ensure that sensitive data about the system environment is not unduly exposed. The variable name would certainly need to include “font”, nonetheless. env(rounded-font, system-ui) seems sensible to me.

PS: Two-part keywords could be a solution as well, e. g.: (system-ui|system-cd) [ [rounded | squared] || [serif | slab-serif | sans-serif] || [fixed-width | full-width | half-width | proportional] || [current | gothic] || …]

[kojiishi]

Agree with @litherum , CSS font cascading is better mechanism than env default value.

[kojiishi]

a browser which supports these fonts but is running on a platform where they aren't relevant, ...

If we skip, we can give authors a choice whether they want to fallback to system-ui or some other rounded fonts by using CSS font cascading. Not strong but doesn't it give more flexibility to authors?

[svgeesus]

it makes more sense that they would fallback to system-ui than to be ignored in the font-family list.

That seems like a good decision

[css-meeting-bot]

The CSS Working Group just discussed system-ui-serif, system-ui-monospaced, and system-ui-rounded.

The full IRC log of that discussion

<dael> Topic: system-ui-serif, system-ui-monospaced, and system-ui-rounded

<dael> github: https://github.com/w3c/csswg-drafts/issues/4107

<dael> Rossen_: myles are you on?

<dael> myles: WE started talking about htis last call

<dael> myles: Refresh memories: 3 new system fonts in macOS and iOS. Question in last call if we add a keyword and platform doesn't have this what happens

<dael> myles: b/c designed to used in system UI having a fallback to match system UI would be best way for itt o work. Proposal is if your'e on a platform that doesn't support requested font, the font is rendered as system-ui rathern then system-ui-serif or whatever is requested. Proposal and open to change

<dael> myles: Other thing from last week is which platforms support these. macOS and iOS support all 3. Android has serif and mono. Windows has sego-script which I think is a goo dmatch for rounded

<dael> myles: Love to hear thoughts

<dael> AmeliaBR: Good point on issue discussion: We have well defined fallback in font spec. If there isn't a match reasonable to not match anything and let author say where they want it to fallback. Author can decide if it's more important to match system or have a style feature.

<chris> fallback to fallback to system-ui seems good to me, but I also appreciate amelia's point about flexibility

<dael> AmeliaBR: Using fallback in the font stack author can decide

<dael> AmeliaBR: Similar, I don't think we should stretch to match sytem fonts. sego script are very different the the rounded. If we encourage browsers to randomly attach fonts they'll end up as useless as current. No one uses "cursive" b/c don't know one device to the next

<dael> Rossen_: Other thoughts?

<dael> myles: To reply. Your first point is fine for fallback. THere was support on issue for both directions to either is okay

<dael> myles: Second point I defer to people working on Window OS what's a good match

<dael> Rossen_: Fair

<AmeliaBR> s/as current/as current generic keywords/

<chris> agreeing with the side point that cursive is almost useless, and fantasy should really be removed from the spec!

<bradk> Good point about cursive and fantasy fonts

<dael> Rossen_: I'm going to have to defer responding until have a chance to discuss with windows fonts team and see if they have a suggestion and if they want to take dependency on

<tantek> bad design of past generic families is not a reason to block an improved modern way to access system-ui variants

<dael> Rossen_: High level I don't think we should have a problem to match a font provided to resolve to accept this

<dael> myles: If people are done discussing feature request there is related discussion on syntax to trigger. If we're done we can migrate to syntax.

<dael> Rossen_: First being if we want to do thi?

<dael> myles: exactly

<dael> Rossen_: Based on GH issue discussion it feels like we're ready to take on this feature?

<dael> myles: Looks like that to me

<dael> Rossen_: I want to resolve on this and then sweat the details.

<AmeliaBR> tantek, no, my point is that we should be careful not to repeat the mistakes of the past!

<dael> tantek: I have an opinion with historical view. Traditional system fonts were derrived directly from windows UI. When impl on mac didn't map well and weren't good design.

<dael> tantek: I read GH and I don't think old system font names should block having this be considered.

<dael> tantek: Similarly, the fantasy and cursive fonts I agree no one uses them b/c unpredictable. If I recall they came from truetype fields. That was before we incubate. We took values from another spec with no demand. I wouldn't count either of htose against htis proposal

<dael> tantek: I looked at GH examples and do present a strong case for having those 3 ways act as system-ui varients if fallback is system UI font. Seems safe and useful, esp for mobile web UIs. That's a strong priority in web, higher fidelity mobile web design

<leaverou> q+

<dael> tantek: i lean strongly toward proposal. Having worked on CSS UI for 20 years I like minimalism

<Rossen_> ack fantasai

<dael> fantasai: I would like clarity on if we use keywords for generic font family or if they are different kind of keyword that can say I don't exist

<tantek> s/priority in web/priority for the web platform

<dael> myles: Prop is generic font family names. If you're on a platofmr where meaningless they're the same as the system UI font family

<dael> AmeliaBR: But there isn't agreement that's way to go

<dael> fantasai: I feel like that makes sense for rounded, but monospace you want to fallback to monospace font

<Rossen_> ack leaverou

<tantek> that would be sensible (fallback to monospace)

<astearns> +1 to mono point - we should just have authors add system-ui to their font stack if that's the intent

<dael> leaverou: Small comment, people don't use cursive b/c ugly, not jsut unpredictable. Second, these keywords seem like they're centered around something Apple did. Not sure what need is or how they work in other platforms. I'm failing to see uscases. In GH most of the discussio is fallback and not why this is needed.

<dael> leaverou: We should have a generic rounded font family, not system-ui-rounded. Seems like we're doing this b/c apple did something and needs to expose and not b/c author want

<dael> myles: We have plenty of requests form people that have attended events and they want to use these fonts.

<dael> leaverou: That's a different point.

<chris> q+ to say, if you want peple to use those fonts, don't hide them!

<dael> AmeliaBR: That people want to use these fonts is different then people wanting an OS tuned rounded font on every OS

<dael> AmeliaBR: If you expose these fonts as a keyword that's mac specific that would be something that could be in a normal font spec

<dael> leaverou: system-ui-monospace has a semantic differnece. I'm using hte system's monospace. If people are telling you they want these fonts they would use them if they're exposed. They're not saying they want a system UI

<dael> myles: On macOS and iOS there is no where in the OS where you can type New York and get these. They're desc by the token of rounded, serif, etc. And that's because we're allowed to change these fonts with the future of OS. That's intentional

<dael> fantasai: Not sure why that means we can't expose the names to the web platform

<tantek> I like the system-ui- prefix from an authoring perspective because it clearly communicates the UI use-case and discourages use in just "content" (body copy etc.)

<dael> myles: Second piece is these are designed to be system UI fonts and not document fonts.

<dael> Rossen_: You're exposing them to be document fonts

<dael> myles: Not intentionally. No way to cripple them in web platform

<Rossen_> q?

<leaverou> q+

<dael> fantasai: Also a number of kinds of fonts. There's fonts only for title. Different fonts for different functions is not a new thing. THere's plenty of fonts that don't have special keyword.

<chris> q-

<dael> florian: And if there's a bunch of people wanting hte pretty font and give a keyword that returns it not but not in the future you haven't given what they wanted

<myles> q+

<tantek> To me the use-case is building mobile web UIs that fit in with the platform. This is a good proposal for solving that use-case.

<dael> Rossen_: Want to timebox to 5 minutes then back to GH. There's a queue. Challanges about exposing font on web layer vs having them exposed behind a keyword was recorded and myles addressed it. Want to go to queue

<tantek> You don't want to use specific named fonts for UI

<Rossen_> ack leaverou

<dael> leaverou: People who said fonts are pretyt, did they mention their use case? How do you know they'll use it right? And people at WWDC much more likely to make Apple specific and I don't want that.

<dael> Rossen_: That point was made leaverou I think myles addressed. myles more to add?

<tantek> We have plenty of things in the platform that can be misused/abused, that in itself is insufficient as an argument. The point is whether a feature is designed to nudge authors toward the positive use-cases, and if so, then it's at least a good feature.

<AmeliaBR> q+ to consider a semi-standard keyword that is cross-browser but single platform

<florian> q+

<dael> myles: Group is right, it's possible to expose using names like any font. We brougt this up to try and be good citizens of web platform and try and figure out if there's interest in having platform non-specific way to get these system ui varients. If group doesn't want we can pick names for them. It will have to be similarly generic, but it's a valid path if group thinks this is not desireable

<Rossen_> q?

<dael> myles: Platform conventions of macOS and iOS this is best match of design intent for these fonts

<tantek> The GitHub issue already addressed how to do Android interop with this too

<dael> Rossen_: Please keep comments as to if we're interested in a feature to have generic system fonts

<Rossen_> ack florian

<Rossen_> zakim, close queue

<Zakim> ok, Rossen_, the speaker queue is closed

<dael> florian: Two points. If we decide against doing this generic and apple does it I would encourage a normal fallback mechanism.

<dael> florian: Second, maybe I misunderstanding use in native system. Increasing ability to mimic native OS seems like a spoofing mech for me to make it look more like it's part of the native app. Already somewhat possible, but maybe not eaiser

<tantek> so add it to the Security Considerations section

<myles> q-

<dael> myles: It is common in web view apps and on the web to display UI as would natively look if native app. One person spoofing is another persons' feature

<Rossen_> ack fantasai

<Zakim> fantasai, you wanted to ask, if Apple exposes these fonts by name, will that solve the use case people have? If not, how do you know? Would it not be better to expose the fonts as

<Zakim> ... regular fonts first and see if there is still a need for system-* keywords?

<tantek> ^^^ this, making mobile web UIs that look native to the platform is a good thing

<tantek> I feel there's a bit of mischaracterizing going on of myles's use-case

<dael> fantasai: I'm still not clear what the strength of use case is for special keywords vs exposing font. Use case you've given us is fonts are pretty. But that's not use case for system-ui-rounded, that's a use case to let people specify the font. If these fonts were exposed with a name, would there still be a need for these keywords? If so, where is demand from?

<dael> myles: I don't have anything new to add

<fremy> @fantasai @myles: I guess if you are making a book-reading experience, you might want to pickup the native serif font

<dael> florian: I don't think you need to report why you don't want to. But if you're okay exposing them, is there still a separate need for the special name?

<dael> myles: Two reasons is 1) they have applicabiliity to other platforms 2) even on apple platforms they are not IDs by name so meaning might change

<dael> fantasai: Keyword can have a meaning change. Font by name you do change the name if you change the style of the font

<tantek> when you author a UI with the web platform, you DONT want to have to specify the specific font by name for each platform, because that's A LOT of extra work. consequence: authors pick 1 or maybe 2 platforms to look good, then others look poor

<dael> fantasai: I don't see the second and a thing that needs to be considered, it's a quirk of the platform.

<dael> fantasai: First case there's a lot of cases where it's not clear if there is one.

<dael> jensimmons: Can I answer that?

<dael> Rossen_: I'd like to close. Please make it quick

<tantek> you really want these kinds of generic font names for web UI, to encourage/enable cross-platform UIs rather than making non-majority platform second-class

<florian> s/But if you're okay exposing them, is there still a separate need for the special name?/But if you had been okay exposing them, would there still a separate need for the special name?/

<tantek> +1 jensimmons. thank you for making this point clearer

<dael> jensimmons: I think from author prospective it would be good if they had access to fonts. If we have system-ui-serif, system-ui-monospaced, and system-ui-rounded as an author they will expect it's different on different OSs. If apple redesigns it would automatically update. People might want to do that as they'r emaking web apps. It's why people like material design. It gives quick access to google design

<dael> jensimmons: I think this would be similar where if you want something to look like OS this is how you do it. Authors might think it's a shortcut to get the pretty fonts, but the primary use case is you want to look like system software

<fantasai> I would be OK with that if it wasn't the only way to get access to these fonts.

<dael> Rossen_: We keep repeating this; do we need to expose specific system fonts and figure out if they will be mapped to what author wants to expose

<Rossen_> ack AmeliaBR

<Zakim> AmeliaBR, you wanted to consider a semi-standard keyword that is cross-browser but single platform

<fantasai> So that if someone wanted to use the font, they didn't have to use a system-ui keyword if they didn't want it to change.

<dael> AmeliaBR: I was going to suggest can we have font keywords that are apple prefixed. Used across browser to match apple font on their system. After this I don't think that's a good idea

<tantek> no I don't want that (apple- prefixed fonts), because THAT is how you get apple only designs. a generic system-ui- font is how you get at least a chance of cross-platform nice looking web UIs

<jensimmons> I would say yes, you need to expose them in this way if Author’s can access them directly. In the past, people could use a font stack that would give them the same result — but without an ability to name these new fonts directly you can’t use the old techniques.

<dael> AmeliaBR: I do think it's a use case to have a system-ui font that works on android and apple and will work on windows in future if they add serif. Important not to force systems without these fonts to match they keywords and instead have normal fallback where authors have control

<dael> myles: If these don't turn into system-ui we would expose as apple prefix.

<dael> tantek: And htat's worse in my opinion

<dael> AmeliaBR: Let's discuss on issue

<dael> Rossen_: I want to close this discussion. Issue is alive and healthy. Let's cover there and bring back maybe next week

<jensimmons> In fact, this makes it easily for Authors to specified OS fonts directly, instead of having to go learn what they are… update when they change… figure out a font stack that works.

<dael> Rossen_: First hting is: is there a need to have a way to target the system fonts for UI purposes.

<tantek> I kind of want to see examples from folks here actually building UIs in HTML+CSS, especially those arguing against the proposal

<dael> Rossen_: jensimmons summary of the use case is excellent. That's in the notes. Please engage on GH. We'll come back next week

<tantek> I see this proposal as improving the situation vis-a-vis existing sytem fonts. That's good enough for me.

[fantasai]

I think my position is, this is a good idea iff:

• The fonts exposed using system-ui-* to the Web are also exposed using regular font names to the Web, so that authors who want to use that specific font don't end up using system-ui-* when they don't actually want the system-ui-* font on other systems, they just specifically like the font that is used on a particular system.
• If that system-ui-* variant does not exist on the system, it falls back as if it were a font that didn't exist, so that the author can specify whether they want to fall back to system-ui or * or something else.

[frivoal]

I see two ways people might want to use these:

• People find these specific fonts pretty and want to use them. If so, the use case is not solved by having keywords that don't promise to match these specific fonts, and merely happen to do so on the first system on which they ship, may stop matching these specific fonts in the future, and will match different fonts on different systems.

• People want to match the look and feel of native apps. In that case, they not only need a keyword to match the fonts that are used in native apps, but also to match the platform conventions about where these fonts are used. And these conventions are OS specific, the resulting layout will be odd on different OSes than the one the author had in mind when designing the page/app. Given that these fonts are fairly generic, and that the current design trends are fairly flat / minimalist, then it may not be too jarring now. But if you comparing very different OS styles, the problem becomes more apparent: if an app is used with these fonts to look native on iOS, it probably would look alright on android, but it absolutely would not look native on windows 95, regardless of how you mapped the fonts.

So, all in all, it doesn't seem to me that the proposal solves the use cases, as I understand them.

I think the way @fantasai is proposing to handle them in https://github.com/w3c/csswg-drafts/issues/4107#issuecomment-525824422 is the way to go if we do it, but I am not convinced we should.

[LeaVerou]

Agreed with @fantasai.

My two cents:

To me, it doesn't look like this is particularly better than an -apple-* name. In fact, it may be worse, because it will be used like an -apple-* name, but it's not syntactically Apple-specific, so it misleads. Not only do these keywords not have a corresponding font in other systems, there is also no interest from other vendors into implementing something similar, and if they do, it will be just because these keywords pushed them to. Also, were these keywords to be added, authors would use them with the expectation that they get those specific fonts, and not what system-ui-* semantically implies. Honestly, these keywords are a band-aid solution to the weird decision to not expose these fonts to the Web platform (which is what's appropriate here and what authors actually want), and we shouldn't contort the CSS language to cater to Apple's branding decisions.

[bradkemper]

I don’t agree that what authors want is to ask for by name for whatever the exact font is today. From what we heard on the call, they want to ask for the system U.I. Serif font, and today get whatever that font is, and tomorrow get whatever it is then.

That said, -apple-ui-* might make a certain amount of sense, if we are sure it truly will not ever be meaningful on non-Apple platforms, other than possibly as an alias of a more general system-ui. But even in Firefox and Chrome, they might still want to get the right font with it in their Mac versions (thus -apple- instead of -webkit-).

[MatsPalmgren]

@litherum What are the IP claims for the fonts that Apple intends to expose? I tend to think that any font that is exposed through a CSS generic keyword ought to be free of any copyright, patent, trademark and other IP claims. Otherwise, if Apple decides to remove these fonts some time in the future, it becomes impossible to faithfully and legally reproduce the rendering of a web page using these fonts.

[Crissov]

@frivoal is right, adaptive font keywords alone would not be enough to mimic system GUIs. The deprecation of system color keywords and the insufficiency of font role keywords are further indications that it is hard to provide an appropriate mechanism that works well across platforms. Authors would need to either know or access various lengths, for instance, as well. [css-env] specifies only a handful of those yet. I now strongly believe that environment variables (our rather constants) are the proper place for all of this, because (while itʼs possible to maintain for font or color names only) we donʼt want to add keywords for all user interface lengths to all the properties they might be used with. A different syntax should also signal to authors that these fonts must not be used like others.

TLDR: Use env() for this!

[litherum]

What are the IP claims for the fonts that Apple intends to expose?

The same as font-family: system-ui, which is already a web standard.

[litherum]

Fundamentally, this proposal is about exposing OS features to the Web. Therefore, getting feedback from OS vendors is crucial.

I don't believe anyone from Microsoft has commented in this thread; I'd love to hear from them about whether this proposal works with the Windows platform. @atanassov

@kojiishi Thanks for commenting here! I'm very excited to hear interest from Google.

[litherum]

As for syntax, I think there are a few contestants:

• system-ui-rounded: Familiar to authors, yet possibly causing compatibility problems if anyone > ever makes a real font with this exact name for some reason. (Note: This concern is relevant to every generic font family name.)
• system-ui(rounded): Simple, yet possibly confusing because font family names are strings in every other context
• env(system-ui-rounded): Conceptually pure, but exposes the platform-specific font name to the Web, if this environment variable was used in another context. E.g. content: env(system-ui-rounded).

@grorg had an idea for one more:

• expanding another property, like font-style, to allow for these styles. So, for example, font-family: Arial; font-style: rounded; would render with Arial Rounded.

[grorg]

Clearly that would rely on some heuristics to identify that Arial and Arial Rounded MT are the same family. Similarly for Roboto and Roboto Monospaced, etc.

[SergeyMalkin]

Fonts can be classified by function or feature. I see confusion about using new proposed values because these two are mixed up.

Function categories may be something like system-ui font family, which is "default font family for system UI". There are also more detailed property values specific to OS vendor: legacy Windows categories like icon, or Apple's -apple-system-headline. I see extending function-based categories as separate issue from property values discussed in this thread.

Proposal here to add system-ui-rounded, system-ui-monospace, or system-ui-serif, doesn't seem to be in this category. I expect, and this is what what I see above in this thread, web developers to use new families because of font design characteristics rather than how they are used in system UI. It is classification based on font feature, which may be well covered by extending generic family values by adding 'rounded' keyword. Only reason for not doing so is backward compatibility. For that reason, I'm ok with adding new set of system-* properties, but because this is feature-based classification I would drop -ui- from property names. And add system-sans-serif to make list internally consistent.

[SergeyMalkin]

And coming back to classification by function, we can try defining another, universal, set of those. This may be hard because of differences in UI design principles and also they tend to change all the time. I any case, if we do this, I agree it should also include other properties like weight. Modern Windows API provides set of categories similar to Apple's (https://docs.microsoft.com/en-us/uwp/api/windows.globalization.fonts.languagefontgroup), which includes width/stretch/style for each category.

[tbrown]

Hey folks! I think this is a great idea, and a good discussion. Please forgive me if this has been covered already or if I’m not fully understanding, but here are some thoughts:

“Serif”, “Monospace”, “Rounded” ... Maybe the syntax for alternate styles of system UI fonts should avoid describing the fonts themselves, and instead describe their intended use — which may not necessarily map to document structure.

@litherum notes that New York, a serifed face, is not the same as other serifed faces:

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.

And @Crissov notes that UI fonts do specific jobs, regardless of how they look:

If the use case is to adaptively mimic the OS look, I expect the OS to actually use these fonts for some part of its GUI. This would not be monospace but console or terminal, not serif but body or document, not rounded but caption or whatever.

So, for examples:

1. Authors start using system-ui-serif for selective content, intending to as @jensimmons said, “blend into the OS”. Then Apple changes the typeface it uses for selective content like this from a serifed face into a bold sans. Does system-ui-serif then reference the bold sans? Would something like system-ui-dramatic (or similar) be more appropriate?
2. Let's say another operating system decided to use a palette of multiple rounded typefaces for its UI. How would a web author reference these? There would be more than one system-ui-rounded. What if instead authors could use something like system-ui and system-ui-secondary?

[jensimmons]

There seem to be a lot of objections to this proposal, but objections based on confusion about what use case this is for.

Imagine an Author who is designing a "PWA" / website, where they want the header of the "web app"/page, including the navigation, to look like the OS the site is on. They might especially want this because their users are saving the site to their home screen, and opening it without browser chrome.

On iOS, they want it to look like Apple's iOS HIG. On Android, they want it to look like Material Design. Same on other systems — ‘mobile’, ’desktop’, TVs, game console, refrigerators, & who knows where — the Author just wants to match the interface for the overall software environment.

At the moment, Authors can attempt do this by carefully designing a font stack. Like these:

/* System Fonts as used by GitHub */
body {
  font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";
}

/* System Fonts as used by WordPress and Medium  */
body {
  font-family: -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ubuntu,Cantarell,"Helvetica Neue",sans-serif;
}



md5-9568b84f255ef793cdbe3517b6a5d940



system-ui
system-ui-serif
system-ui-monospaced
system-ui-rounded



md5-e1dff30012356323507b4f74e6254653



system-ui
system-ui-serif
system-ui-sans-serif
system-ui-monospace



md5-588fd79e28ebcda677d59d8f4363919a



font-family: system-ui-sans-serif, system-ui, Helvetica, Aria, sans-serif;

We already have an entire mechanism for what happens when a font isn't available. Let's use it.

---

This is _not_ about providing access to new Apple fonts to web designers like other normal system fonts. I feel like a lot of this discussion has been derailed by people who are mad at Apple for not making their fonts more "open". Please let's set those feelings aside, and talk about the actual use case at hand — providing Authors with a way to simply and robustly build a font stack that uses the current System UI typography system for the Users OS. Don't punish Authors who need this problem solved because you don't like a particular tech company's choices regarding their new font files.

[frivoal]

@jensimmons Thanks for the explanation.

I feel like a lot of this discussion has been derailed by people who are mad at Apple for not making their fonts more "open".

Apple has at some point during this conversation stated the main reason for wanting this is that designers told them these fonts were pretty and they wanted to use them. That's what brought the "if so, just give them access to the fonts". I don't think anybody was particularly mad at anyone.

Based on the rest of your comment, we can discard that line of reasoning, regardless of how we ended up there.

For the purpose of matching the design of the OS, I am still a bit skeptical, not of the intent, but of how well it is achieved by this: authors will not only need a keyword to match the fonts that are used in native apps, but also to match the platform conventions about where and how these fonts are used. And these conventions are OS specific, the resulting layout will be odd on different OSes than the one the author had in mind when designing the page/app. Given that these fonts are fairly generic, and that the current design trends are fairly flat / minimalist, then it may not be too jarring now. But if you comparing very different OS styles, the problem becomes more apparent: if an app is used with these fonts to look native on iOS, it probably would look alright on android, but it absolutely would not look native on enlightenment, windows XP, WebOS on LG TVs or nextSTEP, regardless of how you mapped the fonts: matching the look and feel of various OSes goes way beyond picking the right fonts. And giving that we don't have tools for that, I am concerned that this will result in making it easier for Authors to ship apps that look like iOS on all iOS browsers (of which there aren't very many), and like iOS-modulo-fonts everywhere else.

Now, maybe authors are going to do that anyway, so we should still ease that pain. But that's not the same as enabling portable apps that look native on any platform.

Actually more thinking is needed here because of SF Rounded... maybe a system-ui-alternative is in order

That seems to play into my concern: system-ui-alternative feels like fantasy generic family: if you don't know what you're going to get, there's not way to use this correctly. And if you build your design based on the assumption that you'll get apples rounded fonts because iphone, then who knows what it's going to do on other systems.

[css-meeting-bot]

The CSS Working Group just discussed system-ui fonts, and agreed to the following:

• RESOLVED: Add them with the `ui-` prefix and make them not match if they're not available

The full IRC log of that discussion

<emilio> Topic: system-ui fonts

<emilio> GitHub: https://github.com/w3c/csswg-drafts/issues/4107

<fantasai> This is my position: https://github.com/w3c/csswg-drafts/issues/4107#issuecomment-525824422

<emilio> myles: should we expose these like any other font like "Times new roman" or as a keyword like a generic font family, which other browsers would also implement and whose behavior would change across OSes

<emilio> ... ?

<emilio> myles: I'd prefer the later

<fremy> @myles: does adding this as a keyword add a fingerprinting method? is it worth it? ;-)

<emilio> fantasai: (explains her position above)

<emilio> fantasai: tldr it makes sense to have system-ui keywords, but they should be exposed also behind an actual name

<emilio> myles: It's impossible for us to determine because the fonts are nice or because they're systemy

<emilio> Rossen_: how are you going to determine it?

<emilio> ... expose it with a proprietary name and you're done

<emilio> koji: I think regardless of exposing them via the name I think there's use case for the keywords

<emilio> florian: I think they should be exposed by name, and if after that there's still users asking for that then we're done

<Rossen_> q?

<emilio> ... but just font families is not the only thing that emulating the system

<emilio> s/that/for

<emilio> myles: but it's a required part of matching the system, regardless of the rest of the design

<emilio> florian: it doesn't seem helpful to use system-ui vs. named, if you can just ua-sniff and set the font name

<emilio> dino: it may help authors in other systems too

<emilio> koji: we learned from system-ui that authors don't want the exact same font as the system

<emilio> ... on windows server a bunch of big pages didn't want the system font which was tahoma, they wanted segoe instead

<emilio> Rossen_: that's why when we released segoe we did it as a font not as a ui keyword

<emilio> florian: that's interesting, so this is appropriate in the sense that people wants ui fonts, but not the system ui font

<emilio> myles: so ui-serif rather than system-ui-serif?

<emilio> florian: if that's the use case that sounds fine

<emilio> nmccully: having a shorthand seems useful to guarantee that the font is current, is there, and not have to worry about the list of system fonts

<leaverou> q+

<emilio> myles: so it seems we're coalescing to add ui-rounded, ui-serif, ui-monospace, ...

<emilio> florian: I'd also also encourage apple to expose them by name

<emilio> nmccully: that seems useful

<emilio> myles: ok, we'll do both

<emilio> florian: less sure about *-rounded

<emilio> fantasai: what do we do for ui-rounded if there's no rounded font?

<emilio> ... maybe you have only arial and times?

<emilio> ... what do you fallback to?

<emilio> florian: I'd propose just for it not to match so it falls back to the next of the list

<emilio> leaverou: if we need more granularity to system ui fonts why mapping them to apple?

<emilio> ... why not system-ui-titletext?

<emilio> myles: when a platform has a different font for titletext we can consider that

<emilio> RESOLVED: Add them with the ui- prefix and make them not match if they're not available

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

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