- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 14 Sep 2023 11:01:16 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-fonts-5] How to add new generic font families`, and agreed to the following: * `ACTION i18n: Propose script-specific generics` * `RESOLVED: Add a generic() function, for generic font famlies that are not defined across all of unicode` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> addison: Another checkin, we've been discussing potentially more generics to support writing/typography traditions in other parts of the world<br> <TabAtkins> addison: Beyond the existing standard set, to let people use named generics rather than requriing authors to hunt for specific font names<br> <TabAtkins> addison: We've discussed this in our meetings<br> <TabAtkins> florian: Status update is same as last time<br> <TabAtkins> florian: Status: complicated<br> <TabAtkins> addison: So partly the status is, mutually trying to gather examples of generic styles that can't just be mentally mapped to the existing generics, where not having the distinction would impair the reading of the doc.<br> <florian> q+<br> <TabAtkins> addison: r12a compiled a doc of langs with stylistic differences that don't fall into the existing buckets<br> <wolfgang> s/requriing/requiring/<br> <xfq> https://www.w3.org/International/articles/typography/fontstyles.en<br> <TabAtkins> addison: Where maybe having named generic would be useful for authors to say what they want and get the desired behavior.<br> <TabAtkins> addison: Challenge is that since they're usually narrowly script-specific, what happens for `nastaliq` in Chinese?<br> <drott> q+<br> <TabAtkins> addison: And also how would CSS encode additional generics, without exploding the set.<br> <astearns> ack florian<br> <TabAtkins> florian: One challenge was, for these things that are only relevant to a subset of unicode, what does it mean for the rest.<br> <TabAtkins> florian: The other is i18n have compiled a list of groupings, but within this there's a gradient of "essential" to "common but authors would survive without it" and everything between.<br> <addison> q?<br> <addison> q+<br> <chris> q+<br> <TabAtkins> florian: So it's a question where the CSSWG wants to place the bar, doing the research to show the distinction is important enouh requires research<br> <TabAtkins> florian: Looking thru books/etc to see that it's a style you need that would not just be visually jarring without, but actually be misunderstood<br> <wolfgang> s/enouh/enough/<br> <TabAtkins> florian: I think elika had a criteria that if we find fonts in the first group it's undeniable we need them, because it causes misunderstandings<br> <chris> qq+ to point to an existing resolution re "the rest"<br> <TabAtkins> florian: But that research is hard. Should probably only be done if we want to be that strict.<br> <myles> q+<br> <TabAtkins> florian: If we're okay with less strict criteria - visually jarring, even if not causing misunderstanding - finding fonts over that bar is much easier<br> <TabAtkins> florian: So where CSS wants the bar will affect how we'll do research<br> <astearns> ack chris<br> <Zakim> chris, you wanted to react to florian to point to an existing resolution re "the rest"<br> <chris> https://github.com/w3c/csswg-drafts/issues/4442#issuecomment-561913410<br> <TabAtkins> chris: We ahve an existing resolution on what to do if they don't apply to the script<br> <TabAtkins> chris: It's in the spec, they just don't do anything<br> <astearns> ack drott<br> <chris> q?<br> <TabAtkins> drott: I think florian's comment was good, about criteria<br> <chris> q- chris<br> <myles> q- i think chris said what i was going to say<br> <myles> q-<br> <TabAtkins> drott: I brought up some ipml questions about what to apply<br> <wolfgang> s/ahve/have/<br> <TabAtkins> drott: For existing generics we usually have UIs and user prefs to apply them.<br> <TabAtkins> drott: If we add a bunch, we'd have to expand that UI, and that could confuse users.<br> <TabAtkins> drott: If we don't add UI, can we agree on the criteria?<br> <TabAtkins> drott: Finding good fonts that recognize the distinctions...<br> <TabAtkins> drott: We have trouble finding them consistently<br> <astearns> q?<br> <TabAtkins> drott: So what are good candidates? Can we agree on how fonts map to the keywords?<br> <TabAtkins> florian: I wonder, if for those values, we can start a registry of known fonts that map to the style<br> <addison> q-<br> <TabAtkins> florian: I don't think blessing some fonts in the spec is fair to font vendors<br> <TabAtkins> florian: But a list of "all these fonts are known to be okay for nastaliq" is okay, UAs can draw from this when picking up from the OS<br> <TabAtkins> drott: If the OS doesn't have it, what do we do?<br> <TabAtkins> florian: fallback<br> <dbaron> Maybe such a list could be in a more editable document that's linked from the spec?<br> <TabAtkins> astearns: That's relevant to the previous issue, you have to define a fallback for anything we add<br> <myles> q+ to ask if there is a specific proposal<br> <TabAtkins> astearns: So we're stuck on finding a criteria.<br> <fantasai> dbaron, https://www.w3.org/2023/Process-20230612/#registries<br> <TabAtkins> astearns: Probably not a good idea to take the most important one and derive a criteria from that?<br> <TabAtkins> florian: i18n has done research and found a bunch that are relevant<br> <chris> q+ to ask if we like the "generic prefix" proposal for new generics<br> <addison> q+ to ask if a new feature would be appropriate<br> <r12a> q+<br> <chris> q?<br> <emilio> florian: maybe we just take i18n's advice directly?<br> <emilio> myles: is there a specific proposal? Not quite sure what we're talking about<br> <TabAtkins> myles: The spec already has pictures of example fonts for many generic famlies<br> <TabAtkins> myles: I don't think we need another document listing more examples<br> <TabAtkins> myles: i think the pictures in the spec are good enough<br> <wolfgang> s/famlies/families/<br> <TabAtkins> florian: Maybe we just take i18n's advice directly and start from their recs<br> <TabAtkins> myles: Is there a specific proposal?<br> <TabAtkins> chris: So there's 3 ways to go.<br> <TabAtkins> chris: One is we add a small, select number of generics.<br> <astearns> ack myles<br> <Zakim> myles, you wanted to ask if there is a specific proposal<br> <astearns> ack chris<br> <Zakim> chris, you wanted to ask if we like the "generic prefix" proposal for new generics<br> <TabAtkins> chris: Two is there's a bunch, possibly hundreds. As soon we find a distinction in a writing system, we add them.<br> <astearns> q++ chris<br> <astearns> ack +<br> <TabAtkins> chris: Three is generics are bad, we add these three and then never again.<br> <TabAtkins> myles: iirc there's a GH issue, and it resolved that 1 and 3 are bad, so that leaves 2.<br> <TabAtkins> myles: We've already solved "what does nastaliq mean in Chinese?'<br> <TabAtkins> myles: If i18n says a bunch of families are useful, let's do it<br> <astearns> ack chris<br> <TabAtkins> chris: so there was a proposal that if we add new generics we add a prefix or something<br> <TabAtkins> chris: problem at the moment is they look like normal font names<br> <florian> q?<br> <florian> q+<br> <TabAtkins> chris: I think the grouping is ugly but more scalable.<br> <TabAtkins> chris: like `generic(nastaliq)`<br> <r12a> q-<br> <addison> q-<br> <TabAtkins> myles: Don't think I have an opinion, except that if we do have a grouping mechanism it should be a function rather than a prefix.<br> <TabAtkins> chris: So that's what I was on the q for, to ask if we want the generic syntax.<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to comment on complete generics vs incomplete generics<br> <TabAtkins> astearns: So should we resolve on adding new font families via generic syntax?<br> <TabAtkins> fantasai: I think we should add a new syntax, but only for incomplete generics.<br> <TabAtkins> fantasai: complete is one that applies to every writing system, it is an endpoint for fallback<br> <TabAtkins> fantasai: monospace, serif, sans-serif are those<br> <TabAtkins> chris: There's not just examples, they're the only ones<br> <TabAtkins> fantasai: No we have system-ui, etc<br> <TabAtkins> chris: No we have a resolution that *those three* always match, the others might fail<br> <TabAtkins> chris: So the "complete" distinction already exists<br> <TabAtkins> myles: Two very similar things<br> <TabAtkins> florian: One is "things that always match across all of unicode, and will never fallback past"<br> <TabAtkins> florian: Then the UI ones which are defined across unicode but might not exist, they can fallback<br> <TabAtkins> chris: Yeah I think that's the distinction.<br> <TabAtkins> astearns: So back to generic functional syntax<br> <TabAtkins> myles: I think if we add a function, the dfn should not be "every generic font family after Sep 14 2023"<br> <TabAtkins> myles: I think it should be somethin like what elika gave, based off the meaning<br> <fantasai> +1 Chris, that's exactly what I meant<br> <TabAtkins> chris: What about names already defined that would fail the criteria?<br> <TabAtkins> myles: We'd keep them for compat but also allow them in generic()<br> <fantasai> (Chris suggested fangsong -> generic(fangsong))<br> <fantasai> myles++<br> <TabAtkins> myles: So the rule for what gets `generic(foo)` and which gets `foo` is based off of something meaningful, not just date added<br> <TabAtkins> fantasai: I think the distinction should be if the font is defined across all writing systems, or is specific to one writing system<br> <TabAtkins> myles: think that's reasoanble<br> <TabAtkins> proposed resolution: add `generic(...)` function, whose values will be the set of fonts that are generic but script-specific<br> <florian> +1<br> <fantasai> s/fonts/generic fonts/<br> <TabAtkins> chris: So that means ui-rounded doesn't get it, it applies across all of Unicode<br> <TabAtkins> myles: Don't have an opinion, sounds fine<br> <TabAtkins> fantasai: of the existing generics, only want would go into generic() is fangsong<br> <TabAtkins> astearns: Objections?<br> <chris> +1 to proposed<br> <TabAtkins> myles: And the reason we're doing this is so that i18n can add a bunch of generic families. Please give us that list<br> <fantasai> ACTION i18n: Propose script-specific generics<br> <TabAtkins> RESOLVED: Add a generic() function, for generic font famlies that are not defined across all of unicode<br> <TabAtkins> florian: Earlier Myles said 3 options, add a few, add a bunch, add nothing<br> <TabAtkins> myles: that was chris<br> <wolfgang> s/famlies/families/<br> <TabAtkins> florian: Ah, I think you said "add a few" and "add nothing" was bad was established<br> <TabAtkins> florian: I thought it wasn't established yet. Want to reconfirm that "add a bunch" is fine.<br> <astearns> +1 to a bunch<br> <TabAtkins> florian: So are we indeed in the situation that we're okay to add a bunch?<br> <TabAtkins> astearns: Any concerns about adding a bunch of script-specific generic font families?<br> <TabAtkins> myles: I think I wrote a set of criteria a few years ago<br> <TabAtkins> myles: There have to *be* at least two fonts that exist that can map to this keyword<br> <TabAtkins> myles: And generic families are only useful for installed fonts, so there has to be popular OSes with an example of that font.<br> <addison> q+<br> <TabAtkins> TabAtkins: I like those rules<br> <astearns> ack florian<br> <astearns> ack addison<br> <fantasai> fantasai: or installed with language packs<br> <TabAtkins> addison: Particularly for small lang communities, who often require installing their fonts, if people, to use their language, install some fonts, and use the necessary generics.<br> <TabAtkins> myles: If everyone is installing a particular font, then content can just name that font<br> <TabAtkins> <br type=lunch dur=60min><br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6770#issuecomment-1719234911 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 14 September 2023 11:01:18 UTC