[css-fonts] system-ui-serif, system-ui-monospace, and system-ui-rounded #4107
Comments
|
What would be the authoring use case for this? When would you use 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 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. )
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 |
|
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. |
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. |
There is nothing baked-in about using Times and Arial for 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. |
|
@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
Let me know if I missed a key part of your objections. Now, addressing these in turn:
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. |
|
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 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. |
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. |
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 |
|
How are existing
|
|
I support the proposal. IIUC @AmeliaBR's points apply not only to this proposal but also to the original
We resolved generic families to serve for 1, while Because the motivation for |
|
Aren't system font's the mechanism for (2)? What's the status of that in other browsers? In Gecko, you can do 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? |
Yep, these get you San Francisco in WebKit on macOS and iOS. None of the existing |
Two reasons:
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. |
This is exactly the reason these are proposed as symbolic family names instead of special font keywords (as with |
Yes, that's s what I meant.
Blink added it a few years ago given web authors' requests, and app-looking sites (eg github) started using it. |
|
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 Apple should probably be proposing iOS, watchOS, tvOS
macOS
I did not find New York being documented for any of that (yet), though. Windows
Furthermore, it is perfectly fine to map the the fonts in question to |
This is probably the most confusing part, but as I read more feedback and articles about The article Using UI System Fonts In Web Design: A Quick Practical Guide explains that the goal is:
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 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 I'm looking into updating Blink's |
|
Thanks Koji, I think I understand the actual issue better now. My problem then is with the Hence, |
|
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.) |
|
The wallet app on iOS uses it as part of the UI: And it’s used throughout the watchOS interface. |
|
I agree with Myles on this. The usecase for By using a By using a generic |
|
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 |
|
|
|
@litherum wrote:
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, a) be skipped over, to the next font in the list, or |
|
The CSS Working Group just discussed The full IRC log of that discussion<dael> Topic: system-ui-serif, system-ui-monospaced, and system-ui-rounded<dael> github: https://github.com//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 |
|
@svgeesus Given the design usage of these fonts, it makes more sense that they would fallback to |
|
Would it be helpful to consider this as a functional notation? Like |
|
As for syntax, I think there are a few contestants:
|
|
@jensimmons Thanks for the explanation.
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.
That seems to play into my concern: |
|
The CSS Working Group just discussed
The full IRC log of that discussion<emilio> Topic: system-ui fonts<emilio> GitHub: https://github.com//issues/4107 <fantasai> This is my position: https://github.com//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 |
|
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). |
|
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? |
|
@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. |
|
Indeed, but this does not quite answer my first question. Does |
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. |
|
No |
Agreed. We shouldn't assume which style |
|
Please open a new issue for it :) |
…cific names for standard font families As per @fantasai's comment in #4107 (comment)
|
@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
I think you also need to clarify that these new values are keywords, like |
If the changes suggested in #4442 are accepted, we can just include these keywords in 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:
|
|
We should change |
fantasai
changed the title
|
I'm seeing a Needs Edits label but am unclear on exactly what edit is outstanding. |
|
Closing as these changes have been made, see for example https://drafts.csswg.org/css-fonts-4/#ui-rounded-def |
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-serifandsystem-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.
The text was updated successfully, but these errors were encountered: