W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2019

Re: [csswg-drafts] [css-fonts] system-ui-serif, system-ui-monospaced, and system-ui-rounded (#4107)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 21 Aug 2019 17:03:08 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-523553193-1566406987-sysbot+gh@w3.org>
The CSS Working Group just discussed `system-ui-serif, system-ui-monospaced, and system-ui-rounded`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: system-ui-serif, system-ui-monospaced, and system-ui-rounded<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/4107<br>
&lt;dael> myles: In latest version of macOS and iOS we've added 3 new fonts. You can see them in this issue<br>
&lt;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<br>
&lt;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.<br>
&lt;dael> myles: THere's nothing you can type in CSS to use these fonts which is unfortunate. Have heard requests to use them.<br>
&lt;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<br>
&lt;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.<br>
&lt;dael> myles: New fonts shouldn't be used as a document typeface<br>
&lt;chris> q+ to ask why making these available on web if by design, they are not to be used in documents<br>
&lt;florian> q-<br>
&lt;dael> myles: What do you guys think about adding a way to get to these fonts?<br>
&lt;dael> Rossen_: Curious if another way is have them in static variables introducing for other system things like scrollbar thickness<br>
&lt;dbaron> I'm curious about whether we want the 'rounded' name in CSS, rather than our existing 'sans-serif' which it seems similar to...<br>
&lt;dael> myles: Mechanically fine. Confusing to authors b/c there's a way to ask for font-family from system.<br>
&lt;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<br>
&lt;dael> leaverou: seems this is adding a very specific language feature that's OS specific. I don't htink we generally do that.<br>
&lt;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.<br>
&lt;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.<br>
&lt;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.<br>
&lt;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<br>
&lt;dael> myles: I see both arguments. Willing to go with WG desires<br>
&lt;chris> I can see merits in both options also. I just want it to be clear.<br>
&lt;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<br>
&lt;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<br>
&lt;dael> AmeliaBR: Fallbacks worth thinking about b/c don't have logical eq in other systems<br>
&lt;dael> Rossen_: Need to think through use cases.<br>
&lt;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.<br>
&lt;dael> myles: It sounds like there's more to discuss so I hope this comes up on a future call<br>
&lt;dael> Rossen_: Will put it on next weeks call as well. Hopefully people can also discuss on github<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4107#issuecomment-523553193 using your GitHub account
Received on Wednesday, 21 August 2019 17:03:11 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:52 UTC