- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Apr 2020 16:36:32 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `generic fonts`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: generic fonts<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/4910<br> <TabAtkins> chris: Myles started a wiki for criteria for new generic fonts<br> <TabAtkins> chris: I changed that to "what are generic fonts *for*"<br> <astearns> https://wiki.csswg.org/spec/css-fonts<br> <TabAtkins> chris: STarted in a very different, latin-centric CSS1 world<br> <TabAtkins> chris: Where we didn't know what fonts were avaiblable, etc<br> <TabAtkins> chris: Need to revisit<br> <TabAtkins> chris: Bunch of issues about generic fonts, but unitl we decide what they're for, we can't progress<br> <TabAtkins> chris: One answer is w etake an axe to them<br> <TabAtkins> chris: Another is "for writing system X you need to distinguish between 3 things, generics only do 1, we need more" so we end up with bunches of generics<br> <TabAtkins> chris: Fine with either solution, but we need to decide and not get a mix<br> <r12a> q+<br> <leaverou> Not sure if this issue is appropriate, but it would be good to have generic font families that are subcategories of the current ones, e.g. rounded-sans, slab-serif etc<br> <r12a> Meet won't recognise my mic<br> <fantasai> r12a, dial in<br> <fantasai> r12a, https://lists.w3.org/Archives/Member/w3c-css-wg/2020AprJun/0066.html<br> <TabAtkins> r12a: So chris outlined two possible routes.<br> <TabAtkins> r12a: There's a third option from Kida-san - "it's so hard to predict what fonts would exist on someone's machine, I'd prefer to use generic fonts all the time"<br> <TabAtkins> r12a: So the thir doption is to deprecate non-generic local fonts entirely<br> <TabAtkins> r12a: Currently the generics are very western-centric, and people can't decide whether they're about style or substance<br> <TabAtkins> r12a: I think generics could be about allowing people in various different writing system to ensure they get a particular type of font, which can be important for different things - like how we use italics for emphasis, they might use a different font<br> <TabAtkins> r12a: Other situations where if you're writing ocntent in Kashmiri or Urghu, and it falls back to a plain nasq font, you lose the cultural signifier, and it becomes hard for Kashmiri/etc to even read it.<br> <TabAtkins> r12a: So if a font doesn't exist on the system you want to go back to a particular type of font, not a random one.<br> <TabAtkins> r12a: Big concern is that people could think up zillions of different types of fonts.<br> <TabAtkins> r12a: I see a gap for i18n<br> <TabAtkins> r12a: For just a few things, not a huge number<br> <TabAtkins> r12a: The things I listed in the thread are pretty fundamental to users of those scripts<br> <TabAtkins> myles: I'm sympathetic to Kida's argument<br> <TabAtkins> myles: Scrapping all generics seems like the wrong direction<br> <xfq_> r12a's list -> https://github.com/w3c/csswg-drafts/issues/4910#issuecomment-619342561<br> <TabAtkins> myles: Content lbockers commonly disallow all webfonts<br> <TabAtkins> myles: So it would be cool for sites without webfonts to stil lhave some control<br> <TabAtkins> myles: So let's not delete the entire generic feature<br> <TabAtkins> chris: Fair<br> <Rossen_> q?<br> <TabAtkins> chris: Another thing that hasn't come up yet is, to what extent is this mapping from teh browser, vs from the user?<br> <TabAtkins> myles: Let's say we gathered this evidence, what woudl tha tinform?<br> <TabAtkins> chris: If the brower, we need a registry saying what types of fonts map to each generic.<br> <TabAtkins> chris: Otherwise we just describe what they do, and the user chooses.<br> <TabAtkins> chris: But most users don't customize, so I'd be wary of that solution.<br> <TabAtkins> myles: Right, the spec right now has some examples and descriptions.<br> <xfq_> Should we start a registry for additional generic fonts? -> https://github.com/w3c/csswg-drafts/issues/4566<br> <TabAtkins> myles: I think that's sufficient, and we don't need a registry of specific fonts.<br> <stantonm> q+<br> <r12a> q+<br> <xfq_> ack fantasai<br> <atsushi> q*<br> <atsushi> q+<br> <TabAtkins> fantasai: I think Richard's point about fonts used for differentation, simialr to latin italics, is a really important point.<br> <TabAtkins> fantasai: We need to solve that problem for all the writing system that need it.<br> <florian> q+<br> <TabAtkins> fantasai: Whether thru generics or whatever, there just needs to be controls for that kidn of differentiation.<br> <TabAtkins> fantasai: Myles point in his wiki draft, that it needs to be something that there are at least two fonts that do it, seems like a base level of requirement<br> <chris> good point that this could be done by new font-style values<br> <TabAtkins> fantasai: For the concern about cultural identity between different linguistic groups, I think that should just b the browser taking language into account when it maps generic fonts.<br> <TabAtkins> fantasai: I don't think we need to add generic font families for every cultural variation, the lang attribute can handle it. That might reduce the number of generics.<br> <TabAtkins> fantasai: So we mainly need to hit where a document uses the same type of text in two or more styles.<br> <TabAtkins> myles: When you have a single element with two different langs, and you style it with a single generic...<br> <TabAtkins> myles: If we want generics to have a meaning across langs, they need to be similar<br> <TabAtkins> myles: So like 'sans-serif' with an arabic character inside, it would need to have a reasonable "sans-serif-ish" font for arabic<br> <TabAtkins> myles: So it makes sense to overload the term and use it for various writing systems.<br> <TabAtkins> myles: But in Richard's list, I don't see much overlap.<br> <TabAtkins> myles: So don't think we can come up with one token that works across those writing systems.<br> <florian> q?<br> <TabAtkins> fantasai: I think you're addressing a different point.<br> <fantasai> https://wiki.csswg.org/spec/css-fonts<br> <TabAtkins> fantasai: I think the stuff that Myles wrote is two good tests; I'd shift the second one to not just be preinstalled, but include "commonly installed", to handle language packs.<br> <TabAtkins> fantasai: Otherwise I'd say that's a good test.<br> <TabAtkins> fantasai: And we need like a goal for new ones. One we shoudl consider is where a single doc needs to differentiate between two kinds of text.<br> <TabAtkins> myles: About the preinstalled vs not, the reason I picked that term is that it's clearly testable.<br> <TabAtkins> myles: You can point to an OS that has it.<br> <TabAtkins> myles: The vaguer it gets, the harder it is to test.<br> <TabAtkins> myles: Hopefully we can come up with a more general term that's still testable.<br> <Rossen_> ack dbaron<br> <chris> +1 to testability<br> <TabAtkins> dbaron: We've had some discussion about "does the user choose" vs "does the browser choose"<br> <TabAtkins> dbaron: In a rough approximation, users don't configure their browsers, so we shouldn't depend on that.<br> <fantasai> Like, what does "preinstalled" mean for a Mongolian user on Linux? It needs to handle common configurations of operating systems, not just pre-installed.<br> <TabAtkins> dbaron: Third option tho is that the font designer chooses.<br> <TabAtkins> dbaron: It would take a longer amount of time to make the feature work well, but I think it's something we should think about.<br> <TabAtkins> dbaron: Something we could design towards in the long run even if it doesn't work in the shor trun.<br> <TabAtkins> dbaron: "Browser chooses" has more power on some systems, where the browser vs OS has more control over installed fonts.<br> <TabAtkins> dbaron: On Mac you can make stronger assumptions than on Linux or Android<br> <TabAtkins> dbaron: On a different topic, another questiona bout generics is, is it meaningful to fall back past a generic?<br> <TabAtkins> dbaron: In CSS2 it was not meaningful to fall back past serif, etc, because there wasn't anything else.<br> <TabAtkins> dbaron: But we could think of generics as covering part of the character space, that could still trigger fallback.<br> <TabAtkins> chris: We did change to allow that<br> <TabAtkins> myles: We changed it to match browsers in fact; the names are just aliases, so fallback can happen normally.<br> <TabAtkins> myles: I think that makes sense with my earlier point about the proposed new names not being generic.<br> <TabAtkins> myles: Best way to handle writing-system-specific names is to allow the browser to fall past sans-serif and hit nastaliq, etc.<br> <TabAtkins> florian: Same with say "nastaliq" on Japanese.<br> <TabAtkins> chris: We can close a lot of issues of "how to match X on Y" with "it doesn't"<br> <xfq_> ack stantonm<br> <faceless2_> +1 to allowing fallthrough, solves lots of problems.<br> <TabAtkins> stantonm: Use-case of ebooks too.<br> <TabAtkins> stantonm: Licensing structure for shipping fonts on ebooks is... hard. Often charge per copy, cost prohibitive.<br> <TabAtkins> stantonm: So a lot of people wnat to use generics.<br> <TabAtkins> stantonm: That way they can get around these licensing issues but still have interesting styles in their books.<br> <dauwhe> q?<br> <xfq_> ack r12a<br> <TabAtkins> r12a: I'm not so sure I agree with fantasai where she says identity isn't tha timportant, i think it's very important<br> <TabAtkins> r12a: I think it's equally important to the toher things she mentioned, matching content to the right font<br> <TabAtkins> r12a: I'm generally dealing with the long tail of the web, watching langauges struggling to get onto the web because we haven't catered to them<br> <TabAtkins> r12a: Many of those, requiring two fonts could be problematic, because they might only have one font for a while, or at least only one good one.<br> <TabAtkins> r12a: So that could prevent these langauge sfrom being equal partners on the web.<br> <TabAtkins> r12a: So in the thread I was playing with the idea of users making the assignment of installed fonts to generic names.<br> <TabAtkins> r12a: I take the point tha tusers dont' mess with prefs much<br> <TabAtkins> r12a: But if you're in northern Nigeria, and everyone around you use a [missed] style of Arabic, you're quite motived to get your browser to produce that type of font<br> <TabAtkins> r12a: So I think we shoudln't deny users the ability to make that association.<br> <xfq_> s/[missed]/kano/<br> <TabAtkins> fantasai: I'm not saying id isn't something we shoudl address, I'm saying it should be automatic when you choose a generic font by taking notice of the lang of the document.<br> <TabAtkins> fantasai: So if you have a writing systme with two variants, country A and country B, if the doc says its in Country B you should get an appropriate style.<br> <TabAtkins> fantasai: Shoudln't require the author to specify a new keywords.<br> <TabAtkins> r12a: My concern is that people developing browsers dont' understand the reqs to make that work.<br> <TabAtkins> fantasai: Agree, so I agree that users shoudl be able to configure; I just dont' think that's a reason for new generic names.<br> <TabAtkins> r12a: Also note that shoehorning some of these into the existing generics doesn't work, too many differentiations and they don't map well to serif vs sans-serif anyway.<br> <dbaron> s/nasq/Naskh/<br> <AmeliaBR> +1 to using names that are actually relevant to the writing system<br> <atsushi> yes<br> <faceless2_> q+<br> <fantasai> s/a new keywords/a new keyword, should be built into the way generics behave generally/<br> <xfq_> ack atsushi<br> <fantasai> s/in Country B/in Language B/<br> <TabAtkins> atsushi: Calling from i18n wg<br> <TabAtkins> atsushi: So for CJK fonts, quite a drudge to make it available via webfonts<br> <TabAtkins> atsushi: Similar generic fonts already in OSes<br> <Rossen_> Zakim, close queue<br> <Zakim> ok, Rossen_, the speaker queue is closed<br> <fantasai> s/webfonts/webfonts, particularly since they can be many megabytes in size/<br> <TabAtkins> atsushi: So defining generics for CJK could help webdevs a lot.<br> <myles> q+ to talk about streamable fonts<br> <TabAtkins> atsushi: And also for epub, it's widely used in japanese publishing industry. ADditional generic fonts beyond serif/sans-serif would help a lot for japanese book publishers.<br> <xfq_> ack fl<br> <TabAtkins> florian: I don't have a strong view as to *how* to address the identity question, but agree it's very important<br> <TabAtkins> florian: EAsy example for Latin speakers - what if the system fell back to Fraktur when the fallback failed? That's what people are living with in other languages.<br> <TabAtkins> florian: So about "what if there's only one font"? In that case you can use it by name.<br> <TabAtkins> florian: And when there are multiples, we can come up with a genric name as needed.<br> <Rossen_> q?<br> <TabAtkins> florian: So we could come up with an at-rule that lets authors specify a font that can get overridden by UAs later<br> <TabAtkins> myles: That's just a @font-face with a local() source, right?<br> <TabAtkins> florian: Hm, if there's no real parsing differences, maybe<br> <TabAtkins> fantasai: What about blockign local fonts? Then it wouldn't work<br> <TabAtkins> myles: STill discussing balance of privacy vs minority fonts, yeah<br> <TabAtkins> florian: Also, letting fonts decide which category they go in - what if it matches multiple categories? Which doyou pick?<br> <chris> q?<br> <Rossen_> ack fantasai<br> <xfq_> ack fa<br> <TabAtkins> faceless2_: I think the list Myles came up with to restrict choices, requiring 2 versions etc, it strikes me that if we make the cost of adding generics much cheaper (like 3rd party registry), a lot of these restrictions wouldn't need to be there<br> <TabAtkins> faceless2_: I'm a big fan of the counter-styles registry, for exaqmple<br> <TabAtkins> faceless2_: Wondering about the interaction there<br> <TabAtkins> fantasai: myles, you said you were against a registry<br> <TabAtkins> myles: No registry can cover every OS/browser combo.<br> <TabAtkins> s/fantasai/faceless2_ /<br> <TabAtkins> faceless2_: Sure, but our groups could maintain that.<br> <TabAtkins> myles: OSes change yearly, who's gonna maintain that?<br> <r12a> for clarity: I was talking about a registry for generic names, but not for assigning fonts to those generic names<br> <TabAtkins> florian: I think this is effectively happening decentralized now - if I want the right font in Japanese, blogs say "if you want to handle these version of Window, Mac, Linux, here's the big font stack to use in your stylesheet"<br> <TabAtkins> dbaron: If we do something like "Window 10 has a new Japanese font we want to use for serif", changing Firefox to do that is sometimes involved, there's webcompat issues, etc.<br> <TabAtkins> dbaron: So maintaining that set of stuff is part of maintaining a browser, it's not just "we can change that and everything's fine"<br> <faceless2_> s/our groups/interested groups/<br> <TabAtkins> myles: Quick mention - atsushi mentioned CjK fonts in particular can be big<br> <TabAtkins> myles: WebFonts WG is currently in the middle of investigating options for streamable fonts, so the browser only downloads the glyphs it actually needs from a font file.<br> <TabAtkins> myles: Some early exploration suggests this is orders-of-magnitude speedup.<br> <r12a> (there are also pages like this https://r12a.github.io/scripts/phrases that would involve downloading LOTS of fonts to display)<br> <TabAtkins> chris: I think we still haven't really solved what generics are for, but we're some ways toward that. I think we can continue in the issue. Shouldn't close the other generic issues until we work out an overarching strategy<br> <faceless2_> @myles actually we've implemented the ability to download parts of fonts already - it's a variation on a loading technique used for PDF. Doesn't work for WOFF2 but for regular OpenType it does. No proper figures on performance but I can look into this<br> <AmeliaBR> ScribeNick: Amelia<br> <AmeliaBR> ScribeNick: AmeliaBR<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4910#issuecomment-621326084 using your GitHub account
Received on Wednesday, 29 April 2020 16:36:34 UTC