- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 28 Aug 2019 16:32:58 +0000
- To: public-css-archive@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> <dael> Topic: system-ui-serif, system-ui-monospaced, and system-ui-rounded<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4107<br> <dael> Rossen_: myles are you on?<br> <dael> myles: WE started talking about htis last call<br> <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<br> <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<br> <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<br> <dael> myles: Love to hear thoughts<br> <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.<br> <chris> fallback to fallback to system-ui seems good to me, but I also appreciate amelia's point about flexibility<br> <dael> AmeliaBR: Using fallback in the font stack author can decide<br> <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<br> <dael> Rossen_: Other thoughts?<br> <dael> myles: To reply. Your first point is fine for fallback. THere was support on issue for both directions to either is okay<br> <dael> myles: Second point I defer to people working on Window OS what's a good match<br> <dael> Rossen_: Fair<br> <AmeliaBR> s/as current/as current generic keywords/<br> <chris> agreeing with the side point that cursive is almost useless, and fantasy should really be removed from the spec!<br> <bradk> Good point about cursive and fantasy fonts<br> <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<br> <tantek> bad design of past generic families is not a reason to block an improved modern way to access system-ui variants<br> <dael> Rossen_: High level I don't think we should have a problem to match a font provided to resolve to accept this<br> <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.<br> <dael> Rossen_: First being if we want to do thi?<br> <dael> myles: exactly<br> <dael> Rossen_: Based on GH issue discussion it feels like we're ready to take on this feature?<br> <dael> myles: Looks like that to me<br> <dael> Rossen_: I want to resolve on this and then sweat the details.<br> <AmeliaBR> tantek, no, my point is that we should be careful not to repeat the mistakes of the past!<br> <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.<br> <dael> tantek: I read GH and I don't think old system font names should block having this be considered.<br> <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<br> <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<br> <leaverou> q+<br> <dael> tantek: i lean strongly toward proposal. Having worked on CSS UI for 20 years I like minimalism<br> <Rossen_> ack fantasai<br> <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<br> <tantek> s/priority in web/priority for the web platform<br> <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<br> <dael> AmeliaBR: But there isn't agreement that's way to go<br> <dael> fantasai: I feel like that makes sense for rounded, but monospace you want to fallback to monospace font<br> <Rossen_> ack leaverou<br> <tantek> that would be sensible (fallback to monospace)<br> <astearns> +1 to mono point - we should just have authors add `system-ui` to their font stack if that's the intent<br> <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.<br> <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<br> <dael> myles: We have plenty of requests form people that have attended events and they want to use these fonts.<br> <dael> leaverou: That's a different point.<br> <chris> q+ to say, if you want peple to use those fonts, don't hide them!<br> <dael> AmeliaBR: That people want to use these fonts is different then people wanting an OS tuned rounded font on every OS<br> <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<br> <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<br> <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<br> <dael> fantasai: Not sure why that means we can't expose the names to the web platform<br> <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.)<br> <dael> myles: Second piece is these are designed to be system UI fonts and not document fonts.<br> <dael> Rossen_: You're exposing them to be document fonts<br> <dael> myles: Not intentionally. No way to cripple them in web platform<br> <Rossen_> q?<br> <leaverou> q+<br> <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.<br> <chris> q-<br> <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<br> <myles> q+<br> <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.<br> <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<br> <tantek> You don't want to use specific named fonts for UI<br> <Rossen_> ack leaverou<br> <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.<br> <dael> Rossen_: That point was made leaverou I think myles addressed. myles more to add?<br> <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.<br> <AmeliaBR> q+ to consider a semi-standard keyword that is cross-browser but single platform<br> <florian> q+<br> <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<br> <Rossen_> q?<br> <dael> myles: Platform conventions of macOS and iOS this is best match of design intent for these fonts<br> <tantek> The GitHub issue already addressed how to do Android interop with this too<br> <dael> Rossen_: Please keep comments as to if we're interested in a feature to have generic system fonts<br> <Rossen_> ack florian<br> <Rossen_> zakim, close queue<br> <Zakim> ok, Rossen_, the speaker queue is closed<br> <dael> florian: Two points. If we decide against doing this generic and apple does it I would encourage a normal fallback mechanism.<br> <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<br> <tantek> so add it to the Security Considerations section<br> <myles> q-<br> <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<br> <Rossen_> ack fantasai<br> <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<br> <Zakim> ... regular fonts first and see if there is still a need for system-* keywords?<br> <tantek> ^^^ this, making mobile web UIs that look native to the platform is a *good thing*<br> <tantek> I feel there's a bit of mischaracterizing going on of myles's use-case<br> <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?<br> <dael> myles: I don't have anything new to add<br> <fremy> @fantasai @myles: I guess if you are making a book-reading experience, you might want to pickup the native serif font<br> <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?<br> <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<br> <dael> fantasai: Keyword can have a meaning change. Font by name you do change the name if you change the style of the font<br> <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<br> <dael> fantasai: I don't see the second and a thing that needs to be considered, it's a quirk of the platform.<br> <dael> fantasai: First case there's a lot of cases where it's not clear if there is one.<br> <dael> jensimmons: Can I answer that?<br> <dael> Rossen_: I'd like to close. Please make it quick<br> <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<br> <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?/<br> <tantek> +1 jensimmons. thank you for making this point clearer<br> <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<br> <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<br> <fantasai> I would be OK with that if it wasn't the only way to get access to these fonts.<br> <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<br> <Rossen_> ack AmeliaBR<br> <Zakim> AmeliaBR, you wanted to consider a semi-standard keyword that is cross-browser but single platform<br> <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.<br> <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<br> <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<br> <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.<br> <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<br> <dael> myles: If these don't turn into system-ui we would expose as apple prefix.<br> <dael> tantek: And htat's worse in my opinion<br> <dael> AmeliaBR: Let's discuss on issue<br> <dael> Rossen_: I want to close this discussion. Issue is alive and healthy. Let's cover there and bring back maybe next week<br> <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.<br> <dael> Rossen_: First hting is: is there a need to have a way to target the system fonts for UI purposes.<br> <tantek> I kind of want to see examples from folks here actually building UIs in HTML+CSS, especially those arguing *against* the proposal<br> <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<br> <tantek> I see this proposal as *improving* the situation vis-a-vis existing sytem fonts. That's good enough for me.<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-525823192 using your GitHub account
Received on Wednesday, 28 August 2019 16:33:00 UTC