- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 Oct 2021 17:04:39 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `generic font families`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: generic font families<br> <r12a> Writing systems around the world use a wide variety of alternative writing styles. These writing styles may support functional differences between text, or may have cultural relevance, in addition to aesthetic concerns.<br> <r12a> The inability to control what style of font is delivered during fallback can be problematic to international users. A Thai user may not want text to fall back to a looped style if an alternative non-looped font is available. A Kashmiri or Urdu user will certainly want content to fall back to a nastaliq font, if one is available, rather than one of the naskh fonts they are likely to have on their system. And so on.<br> <r12a> The current set of categories for generic font fallbacks are modelled on a Western world-view, and don't map onto the needs of international users. Trying to stuff the needs of other writing systems into the current Western categories is not really feasible, not to mention that it potentially creates confusion for would-be users.<br> <r12a> Browsers should allow users to define their own generic fallback fonts for writing-system relevant categories. An attempt may be may to enumerate those categories in a registry, or users may be allowed to define them for themselves. However, apart from some defaults, the browser shouldn't attempt to restrict which fonts apply to which category – users should be able to match fonts to categories. The mechanism involved could be very simila<br> <r12a> r to, or perhaps even just an extension of, existing mechanisms for defining font preferences in browsers for proportional, serif, sans-serif, and monospaced fonts.<br> <xfq> GitHub: https://github.com/w3c/csswg-drafts/issues/4910<br> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <myles> q+<br> <chris> q+<br> <astearns> ack myles<br> <TabAtkins> q+ astearns<br> <TabAtkins> myles: I hadn't seen this before, interesting<br> <TabAtkins> myles: You mentioned a user-created generic font family<br> <TabAtkins> myles: Are you describing that a user could make a font-family named "myles" and a website coudl use it?<br> <TabAtkins> myles: Or that the generic families are still defined in CSS, but users control what fonts map to the family<br> <Peter> q+<br> <TabAtkins> r12a: Yes, one of those. More details need to be worked thru.<br> <TabAtkins> r12a: Discussion about english-specific details of the existing generic fonts<br> <TabAtkins> r12a: But having a registry could be slower, but would give us control over what's available<br> <TabAtkins> r12a: There's lots of different styles for non-latin scripts<br> <astearns> ack chris<br> <TabAtkins> r12a: But the main thing is I want a mechanism where a user can control which fonts belong to which category<br> <TabAtkins> chris: So there's two ways we can do it with generics<br> <r12a> q+<br> <TabAtkins> chris: One way is, we had five originally, two are stupid we can drop them, and we dont' add more. If you want fonts use a webfont. Workable, but not everyone will have fonts.<br> <TabAtkins> chris: The other way is to have a whole bunch of categories which don't map to anything for many scripts<br> <florian> q+<br> <TabAtkins> chris: So the issue is a clash with existing terms - if we add a "myles" generic, need to figure out how that interacts with webfonts named "myles"<br> <TabAtkins> chris: I think the "thousand flowers" approach is where to go, we just need to be clear about it<br> <TabAtkins> astearns: I'm a little concerned about this user-definitions scheme, that we'll put a lot of burden on users of a particular language<br> <chris> qq+<br> <TabAtkins> astearns: Yes, perhaps there's a registry entry for nastaliq, but if it's user-defined then every user has to fiddle with settings to create a nastaliq entry and associate a font<br> <TabAtkins> astearns: I think if we do a registry there should be a way to graduate it to "official" where it's supproted by default in browsers<br> <astearns> ack chris<br> <Zakim> chris, you wanted to react to chris<br> <astearns> ack astearns<br> <myles> +1 to what Peter is saying<br> <TabAtkins> Peter: Having the user have thea bility to create a generic family doens't seem that useful - how does the author know what the users are exposing?<br> <TabAtkins> Peter: Having the user be able to associate fonts with a generic family does help with another issue on the list<br> <TabAtkins> Peter: Relatively small communities get a preferred font on their system<br> <TabAtkins> Peter: And if it's something the browser uses but doesn't expose tot he content, that addresses the privacy/fingerprinting concerns<br> <astearns> ack Peter<br> <TabAtkins> Peter: If we have a thousand generic families, that seems like a mess<br> <TabAtkins> Peter: Even in western-centric families, they quickly fail<br> <TabAtkins> Peter: Type doesn't fit nicely into categories<br> <TabAtkins> Peter: So you ahve an issue - what does the author consider a 'fantasy' font vs the end-user, and are they agreeing?<br> <chris> fantasy should be deprecated honestly<br> <astearns> namespace problems could be solved by using functional notation: generic-font(myles)<br> <myles> q+<br> <TabAtkins> Peter: If the user goes to a site do they expect their font to be used on a given author's site?<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <TabAtkins> r12a: I think content authors could choose a font, and the problem is what if it's not availalbe on the user's system<br> <TabAtkins> r12a: Like for nastaliq, Urdu speakers really don't want a nasq (sp?) font, they always want nastaliq<br> <TabAtkins> r12a: So I think those users need a way to define what happens when a particular writing style is used<br> <astearns> ack r12a<br> <astearns> ack fl<br> <TabAtkins> florian: I think a few of the problems aren't taht bad<br> <xfq> s/nasq (sp?)/naskh/<br> <TabAtkins> florian: If the list is populated by users it would be confusing - extensions could potentially expand for them<br> <TabAtkins> florian: If we have a bunch of UA information - a browser on Mac knows what fonts the system ships with, they cna prepopulate<br> <TabAtkins> florian: But for the registry, we can graduate to official only if at least one browser wants to ship with a default assignment<br> <TabAtkins> florian: So then authors have a list of known groups, and users/UAs can add more<br> <TabAtkins> florian: So yes, there are many, but only supported ones hit the registry<br> <TabAtkins> florian: For the name clash, we can just namespace into a function if we need to<br> <chris> yes, I like the idea of a generic() function<br> <astearns> ack myles<br> <TabAtkins> myles: This is a meta-issue that's been going on for over a year, lots of comments and participants<br> <TabAtkins> myles: Often when CSSWG discusses meta-issues there are opinions bu tnot much issues<br> <r12a> q+<br> <TabAtkins> myles: Maybe we want to say "no policy, but we'll discuss individual requests as they come" and close the issue?<br> <TabAtkins> r12a: That's sort of avoiding the problem<br> <TabAtkins> r12a: We think users need a solution<br> <TabAtkins> myles: I'm not saying we wouldn't have new changes, I'm saying we could discuss those for specific proposals rather than having an overarching principle<br> <TabAtkins> astearns: This issue isa bout the principle, and was started in part to *shut down* dicussino of new generics<br> <TabAtkins> astearns: Think it makes sense to have an issue about how to have new generics<br> <chris> r12a should put an I18n-needs-resolution label on 4910 in that case<br> <TabAtkins> fantasai: I dont' think it's a good idea to have user-defined generics, makes more sense to ahve them in the spec<br> <TabAtkins> fantasai: Need to be more open to ahving generics because there are a lot more necessary<br> <TabAtkins> fantasai: richard brought up a point about users wanting a certain style of font over another<br> <astearns> I think the idea of having user tweaking of UA-defined generics is really interesting<br> <TabAtkins> fantasai: That shoudl be handled in user settings by setting the generics to the appropriate style<br> <TabAtkins> fantasai: That doesn't need a new generic<br> <TabAtkins> fantasai: When it is needed is when a variant conveys meaning<br> <TabAtkins> fantasai: Like in english using italics for emphasis. Those are shifts in the family but it's not really a different shape.<br> <TabAtkins> fantasai: [missed]<br> <TabAtkins> fantasai: Those kidns of things describe a shift<br> <TabAtkins> fantasai: When those aren't bold or italics but rather a style of font we need to make sure the fonts have that style<br> <TabAtkins> fantasai: So we need generics for those cases at a minimum<br> <TabAtkins> fantasai: Maybe for more reasons, like our recent 'rounded', which can be done case-by-case<br> <TabAtkins> fantasai: But we need to be more open to generics that only have meaning for some scripts<br> <r12a> international users use specific font categories of font to change the font style where we might use bold or italic in English<br> <TabAtkins> fantasai: While trying to have them be as broad of a range as possible<br> <TabAtkins> astearns: Out of time, but I think it woudl be good to have a new separate issue about how to introduce new generic fonts families syntactically<br> <chris> I volunteer to raise the new issue on adding generics<br> <TabAtkins> astearns: Not this meta issue about whether to do it at all<br> <TabAtkins> astearns: We didn't get to the user-installed fonts issues<br> <TabAtkins> astearns: But we have a longer-form meeting scheduled next week<br> <chris> yay!<br> <TabAtkins> astearns: We could invite you at a scheduled time block<br> <TabAtkins> astearns: I'll contact you about that<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-953127524 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 27 October 2021 17:04:42 UTC