Csswg-drafts: [meta] [css-fonts] Criteria for generic font families

[litherum]

This issue is a meta-issue regarding procedures for the CSSWG itself. This issue will not result in a change to any specification.

I've put some proposed text on https://wiki.csswg.org/spec/css-fonts regarding a test that each new proposed generic font family should have to pass.

For each new generic font family proposed, the proposed generic font family must pass a test to be considered to addition to the spec. This test is necessary, but not sufficient, for its addition.

The purpose of this test is to limit the proliferation of generic font families.

1. There needs to be at least two distinct fonts in the world which can map to the generic font family. In this case, “distinct” requires that they are invented by different unaffiliated people or groups.
2. Because generic font families are only relevant for installed fonts, at least two major distinct operating systems need to ship a font which would be mapped to this generic font family. Again, “distinct” requires that the operating systems are invented/maintained by different unaffiliated groups. These two OSes can ship the same font.

I put this on a wiki page in accordance with https://github.com/w3c/csswg-drafts/issues/4606#issuecomment-577736282 where we resolve for me to start a wiki, and whatever we decide will be edited into that wiki page.

[frivoal]

Thanks for starting this.

I'm wondering about the second criteria. The categorization of individual font families into generic fonts is done by the browser rather than by the OS itself. You are right that generic font families are only relevant for installed fonts, but from the point of view of the browser, it doesn't matter all that much if the font came bundled with the OS, was installable as an option (whether as part of some OS language pack, via Debian's apt install, or some similar mechanism), bundled with some common piece of software (MS Office?), or whether installed manually by the user.

I think I agree that it needs to be commonly available/installed, as browsers (and specs) can't possibly be expected to categorize every font under the sun, but commonly available isn't 100% the same as preinstalled by the OS.

I'm not 100% sure how to capture that though. Maybe keep point 2 as it is, but add something like "An exception may be granted in the case of fonts that do not ship with an operating system but are nonetheless widely installed."

PS: Depending on exactly https://github.com/w3c/csswg-drafts/issues/4055 / https://github.com/w3c/csswg-drafts/issues/4497 turn out, this may interact/overlap with that.

[litherum]

I’m not sure I agree. There’s nothing in a font file which indicates whether it would be a good fit for “fantasy.” Browsers have to come up with that mapping by hand, ahead of time. Therefore, the set of fonts that are shipped with the OS is really the relevant set here.

The definition of “OS” is fuzzy, though. If you define Linux as “just the kernel” then it includes 0 fonts. If you define Linux as “whatever you get when you say apt-get install kde” then that starts to make more sense, though it’s debatable whether this would count as “major.”

[Crissov]

FWIW, I have changed the wiki page to use the more fuzzy term _platform_ instead of _operating system_.

[aphillips]

Similar to the discussion of fingerprinting user-installed fonts, I'd be a little concerned about generic fonts requiring some sort of universal support as this pertains to non-Western publishing traditions. When a user names a generic font, they expect the browser will select some font and that this font will be at least somewhat consistent with the "generic" intention of the name. E.g. if I specify sans-serif, I'd be satisfied with Helvetica, Futura, Arial, or Franklin Gothic and seriously disappointed by Zapf Chancery.

For non-Western publishing, the existing generic names are a little restrictive. Somewhere in this repo there is a discussion of whether cursive means fonts such as Kaiti in Chinese. And there are styles such as the rounded yuan style fonts that have no specific way to be generically selected. Similarly, Arabic script fonts have well-known styles that don't neatly map to serif/sans/etc. e.g. there are nastaliq, nashk, and ruqh styles. See for example here or the gap analysis document here.

Not every platform installs fonts for all of these scripts nor supports all of these typographic variations out of the box. They may be installed only on specific locale versions or (especially for minority languages) they might require custom installation. I tend to think that allowing for generic names that support different typographic and publishing traditions explicitly would be a worthy addition to CSS and the mooted second rule seems biased against that possibility.

[Crissov]

Is there any WG consensus on what should be covered (thus necessarily pass the test) and what should definitely not be covered (and therefore preferably fail the test)?

[astearns]

@Crissov I do not think there is consensus on any specific proposal for a new keyword. That’s why we’d like to set down some criteria to evaluate specific proposals. I do think there is consensus that the criteria should be strict enough to exclude at least fantasy if we were able to re-evaluate current generic font families.

[Crissov]

I can think of a number of (Western and material) terms that could be useful and most would probably match a pre-installed font on both Windows 10 and macOS, but Iʼm not sure at all whether the CSSWG would want them, e.g.

• Fraktur, blackletter, medieval
• Egyptienne, slab serif
• Garamond, book serif, conservative
• Times, newspaper serif
• Futura, geometric sans-serif, modern
• Helvetica, neutral sans-serif
• typewriter (messy monospaced)
• handwriting (specific cursive)
  
  
  
  • chalk on blackboard
  
  
  • felt marker on whiteboard, notes
  
  
  • nib or pen on parchment, calligraphic, chancery script
  
  
  • pencil on paper, scribble, comic
  
  
  • brush on paper
  
  
• Trajan, chisel in stone, engraved, monumental, movie poster

The following would pass the first but not the second criterion:

• scifi, futuristic (specific fantasy)
• art deco
• heavy metal, spiked
• graffiti
• dot matrix, LED
• segmented, pocket calculator, LCD
• illuminated / ornamented letters
  
  
  
  • animal tracks
  
  
  • animal shapes
  
  
  • human silhouettes
  
  
  • winter, icy, snowy, cold
  
  
  • spring, floral, blossoms, leaves
  
  
  • summer, sunny
  
  
  • autumn, leaves, harvest
  
  
  • scary, bloody
  
  

Iʼm not proposing any of these here. I just think it would heron to know what the actual goal is.

[litherum]

@aphillips You make some good points!

My original criteria didn’t mention language support or internationalization, and that was somewhat on-purpose.

We, the CSSWG, could go two different ways:

1. Add an additional criterion that all new generic font families must be meaningful for many scripts / writing systems, or
2. Don’t add such a criterion, and if a new proposed generic font family is meaningful for a bunch of scripts / writing systems, then that’s cool, but if not, then it’s still fine.

Option 1 might unduly restrict the set of new generic font families. I think most of the existing font families we have today would fail this test. Or it might _not_ unduly restrict the set, and we might all live in a world where there are plenty of generic font families and authors can choose any style they want and it all _just works_ in any language. Who knows!

Option 2 might possibly lead to a world where each script has a bunch of distinct generic font families, and people unfamiliar with these scripts will have no idea what any of them mean. This, honestly, might be totally fine! I don’t know.

Hopefully someone smarter than me can indicate whether option 1 or 2 is better. So, yeah, I simply just didn’t mention language support or internationalization in this proposal.

[fantasai]

Fwiw, here's the minutes of the generic font family criteria discussion: https://lists.w3.org/Archives/Public/www-style/2020Feb/0013.html

There was also one "sufficient, but not necessary" criteria proposed in that discussion: do typographers in typical publications use distinctions between different these groups of fonts for semantic purposes?

[litherum]

I don’t think any criteria listed ahead-of-time can be sufficient criteria. Each new proposal needs to be considered in its entirety by the WG. Certainly some criteria can demonstrate benefits of a particular proposal, but someone’s ability to demonstrate some criterion shouldn’t allow them to skip the standards process.

[xfq]

The i18n WG would like to participate in the discussion of this issue at the next F2F: https://www.w3.org/2020/04/09-i18n-minutes.html#item07

Adding Agenda+ F2F.

[svgeesus]

I thank @litherum for starting this meta-issue and would like to slightly broaden it from _criteria for new generic font families_ to _criteria for generic font families_. In other words, it seems necessary to revisit why we (continue to) have generics at all, what authoring purpose they are intended to serve, what are their semantics, and then potentially deprecating some of them.

The generics in CSS1 described a very different world: downloadable fonts had yet to happen, platforms were simpler and more limited than now, in particular regarding I18n; and CSS was seen much more as a set of vague stylistic hints that might be interpreted quite broadly. The CSS1 generics had three members which made stylistic sense from a Latin-centric worldview: proportional serif, proportional sans, fixed width for code listings; and two vaguely defined and aspirational members which were of questionable utility even then.

Are generics intended to capture the _use_ of fonts (formal, playful, etc) or the _appearance_ (regardless of the cultural meanings attached to that appearance in some writing systems)?

Do generics make sense in a world where downloadable fonts are the norm and generics merely influence fallback?

The lack of clarity on intended semantics became clear as soon as the application of the original set to other writing systems was attempted (are all Arabic fonts cursive? what does fixed-width signify for writing systems where most glyphs are fixed width?) and when the initial set was extended to cover other writing systems with different categories (such as a category somewhere in between serif, sans, and cursive).

I feel that we can't reasonably define the existing generics or indeed extend them, without clarity on their purpose.

Great f2f topic!

[svgeesus]

Option 1 might unduly restrict the set of new generic font families. I think most of the existing font families we have today would fail this test.

And we might then consider deprecating those generics. Or not.

Or it might not unduly restrict the set, and we might all live in a world where there are plenty of generic font families and authors can choose any style they want and it all just works in any language. Who knows!

Or, thirdly, there are plenty of generics and some of them are useful to some communities but most are opaque and/or useless to most communities. Which might still be okay!

[svgeesus]

Issues (some closed) whose resolution _could_ be informed by this meta-issue:

• Proposal for a new generic font family "Rounded"
• The Cursive = Chinese Kaiti equivalent
• Should we start a registry for additional generic fonts?
• which generic in a font-family list influences system fallback?
• Inconsistency between monospace and ui-monospaced
• Add a ui-sans-serif keyword to go with ui-serif
• Don't require browsers to always match every generic font family to a concrete font family
• What does fangsong map to for non chinese text
• Specify what generic font family maps to nastaliq
• system-ui-serif, system-ui-monospace, and system-ui-rounded
• Should emoji be restricted in its range?
• list of generic font-family keywords is out of date
• Do generic fonts resolve to a single font face value?
• Allow CSS.supports('font-family: system-ui') for feature detection

[fred-wang]

Just for the record, font-family: math is important as math formulas generally use special fonts differing from the surrounding text in order to produce good rendering. The criteria given in the spec (presence of an OpenType table for math layout purpose) is good enough to distinguish them from text fonts. Existing math fonts as WOFF are generally large, making downloadable fonts less attractive. Users are also willing to configure their preferred font for math, so a generic name is useful. Currently, WebKit has a hardcoded font-family list of math fonts in the UA sheet while Gecko uses an internal "math" lang to make the math font configurable like other languages. MathML Core relies on font-family: math as a more standard approach covering that use case.

[Crissov]

Are generics intended to capture the use of fonts (…) or the appearance (…)?

Thatʼs both a good and important question. If the correct answer is the latter, PANOSE could probably still inform new generics to add.

[faceless2]

Anyone specifying font-family: fantasy in 2020 is essentially saying they don't really care which font is used. Deprecate it; it will fall back to the system default, which is as valid as any other result. Personally I'd then swing the same axe at "emoji" (preferring font-variant-color or similar to replace it) and "cursive", although perhaps the "kaiti equivalence" issue would make the latter a harder prospect.

Beyond that, unless there's a very, very specific purpose (math, probably fangsong and kaiti, and the various ui-* fonts for native OS appearance), I would vote to keep the door on new generic fonts firmly shut. Universal consensus on categories in a modern, multilingual web seems very unlikely, and if we manage to achieve it? We've just added a feature that is literally designed to give varying results across browsers and platforms. It seems a step in the wrong direction.

[kojiishi]

Beyond that, unless there's a very, very specific purpose (math, probably fangsong and kaiti, and the various ui-* fonts for native OS appearance), I would vote to keep the door on new generic fonts firmly shut.

Could you explain a bit more about why we want to keep fangsong and kaiti but want to reject other script-specific families? I had an impression that we want to be consistent on all script-specific generic families, but it looks like you disagree, and I'm curious why you think so.

[faceless2]

CJK fonts are not my area of expertise - I don't have a strong position on these two. I know their size makes them an awkward download, "Fangsong" has already been added, and I understand there was some history behind both "FangSong" and "Kaiti" as generic families - enough to make them an exception. I'm very happy to be corrected on this.

If the aim is to be consistent - adding "fangsong" or "nastaliq" just because we added "serif" - then we're going to be adding a lot of them. We've already had the debate of how to style latin text when "fangsong" is the font family, and how to style chinese text when "cursive" is the family. The more generic fonts we add, the harder this gets - how do you style chinese text when "nastaliq" is the font-family? If we want consistent rendering we have to have that discussion. And I think for the vast majority of cases, where people are already embedding fonts as a solution, it's not very useful.

The bar @litherum set at the start of this discussion is excellent, but it shouldn't be a minimum criteria to meet. The primary criteria should be "what specific technical problem is this particular generic font going to solve?" If we can't answer that, we shouldn't add it - or keep it.

[xfq]

The more generic fonts we add, the harder this gets - how do you style chinese text when "nastaliq" is the font-family?

Although I don't have an answer now, in https://github.com/w3c/csswg-drafts/issues/4442#issuecomment-561913410 we resolved that only serif, san-serif, and monospace must match a font and all other generic fonts should only match if/when appropriate/possible.

[r12a]

It seems we are fumbling about in the dark a bit wrt what specific technical problems generic fonts solve. Perhaps the following will throw in a chink of i18n light that may help.

The following is all about situations where if you pick up a fallback generic font you’d really want it to be of a particular type.

I try to show some examples of situations where falling back to an arbitrary font could be problematic because the writing style performs a practical function that either suits it for a particular audience/region (identity) or helps distinguish some content from other content (semantics). In other words, the differences pointed to here are not just cosmetic.

There can also be ‘mechanical’ implications, in that some writing styles use a different character repertoire than others, meaning that text may not render properly on fallback, or may be adapted to specific behavioural features (such as the differences in justification behaviours for naskh, ruq’ah, and nastaliq fonts).

Follow the links for examples. This is not an exhaustive list.

Adlam (Pular)

See https://r12a.github.io/scripts/adlam/#writing_styles

A _cursive writing style_ (ie. one where the letters are joined up) is the norm.

An _unjoined writing style_ is used for display fonts in books and articles to clearly distinguish titles. It is also used for social reasons in educational contexts (because the unconnected script is easier to learn).

Fallback to a cursive font would reduce the distinctiveness of titles, but would also have an impact on readability for educational materials.

N’Ko (Maninka, Bambara, Dyula, ...)

See https://r12a.github.io/scripts/nko/#sample (i have no example of unjoined yet)

A _cursive writing style_ (ie. one where the letters are joined up) is the norm.

An _unjoined writing style_ is used for display fonts in books and articles to clearly distinguish titles. (Don’t know about educational usage.)

Fallback to a cursive font would reduce the distinctiveness of titles.

Arabic (Standard Arabic, Azerbaijani, Central Kurdish, Hausa, Kashmiri, Luri, Mazanderani, Punjabi, Northern Pashto, Persian, Western Panjabi, Dari, Sindhi, Saraiki, Uyghur, Urdu, Northern Uzbek, Malay,…)

Arabic orthographies can be grouped into a number of writing styles, some of which are more common for particular languages, while others can be used interchangeably for the same language. Sometimes the variations are adapted to usage, for example book text vs. inscriptions; sometimes the variants reflect regional, cultural or stylistic calligraphic preferences.

For a brief introduction to font styles, with examples, see https://w3c.github.io/alreq/#h_writing_styles. Not all writing styles are described here.

The _naskh writing style_ is the most prominent style for the Arabic language, and has become the default form of Arabic language content in most contexts. See https://r12a.github.io/scripts/arabic/#sec_naskh_style

The _nasta’liq writing style_ is the standard way of writing Urdu and Kashmiri. It is also often a preferred style for Persian text. Key features include a sloping baseline for joined letters, and overall complex shaping and positioning for base letters and diacritics alike. There are also distinctive shapes for many glyphs and ligatures. See: https://r12a.github.io/scripts/arabic/urdu#writing_styles

Falling back to an arbitrary font (usually naskh) significantly affects the identity and the readability of the content for speakers of Urdu and Kashmiri.

The _ruq’ah writing style_ is commonly used in education, in official documents, and for every-day writing. It is known for its clipped letters composed of short, straight lines and simple curves, as well as its straight and even lines of text. It is a functional style of writing that is quick to write and easy to read. It also doesn’t extend baselines, like a naskh font does. In 2010's rebranding of Amman, Jordan, a ruq'ah font family was created to serve as an italic face alongside a naskh regular font. See https://r12a.github.io/scripts/arabic/#sec_ruqah_style

Falling back to a non-ruq’ah font removes the effect of handwritten text and may remove the distinction between italic vs. regular styles in signage and other content using the FF Amman font in Jordan.

The _kano writing style_ is a common way of writing Hausa, especially in Northern Nigeria, in the ajami script, and like other West African writing it is based on Warsh (Warš) forms, which incorporate Maghribi characteristics. Text written in the Kano style will include glyphs for a number of African characters that may not be available in the average naskh font. See https://r12a.github.io/scripts/arabic/hausa#writing_styles

Falling back to an arbitrary font will remove the identity of the content, and is likely to cause rendering failures for African characters. In fact, there is another orthography that looks much closer to naskh that is used with hand-written adaptations for the newspaper Al-Fijir, based on the Hafs orthography, but when writing in that orthography you need to use different code points from those used for the Kano style. So falling back to this would presumably lead to some confusion.

The _kufi writing style_ is the original style used for the Koran, but is not used for newspapers or official content today. However, it is used in modern content for logos and other stylised applications. See https://r12a.github.io/scripts/arabic/#sec_kufi_style

Falling back to an arbitrary font would lose the decorative distinctions provided by the kufi font. This is, however, not quite the same as failing to render a Latin decorative font, since for Arabic this is a writing style, and there are likely to be other kufi style fonts on the system that would retain the decorative distinction intended.

Syriac (Syriac, Assyrian Neo-Aramaic, Turoyo, …)

Syriac has 3 major variant writing styles, Estrangelo, Serto (Western), and Madnhaya (Eastern). The code points for the consonant letters are the same, but the shapes of the letters and code points and shapes of vowel diacritics can vary significantly. Also, it is normal not to use code points for vowel diacritics in estrangelo text, whereas when writing the serto Turoyo language, or generally the madnhaya Assyrian dialects, the script has evolved into an alphabetic one that is fully vowelled. Noto provides separate fonts for each style, but my Mac falls back to the Noto Sans Syriac Eastern (the Madnhaya writing style), regardless of the language tags applied (syr, aii, tru, syr-Syrc, syr-Syrn, syr-Syre). (And by the way, the harmonisation of shapes in the Noto fonts neutralise much of the local flavour of these styles, if you compare with other fonts.)

The _estrangelo writing style_ is used in all ancient manuscripts. West and East Syriac text uses it for headers, titles, and subtitles. It's also the current standard for Western scholarship. See https://r12a.github.io/scripts/syriac/#writing_styles

Falling back to a different writing style would reduce the distinctiveness of headings in languages that use East & West Syriac. For text in the Syriac language it would just look wrong.

The _serto writing style_ is used in West Syriac texts, the modern orthography for Turoyo, and Garshuni (Arabic written with Syriac). See https://r12a.github.io/scripts/syriac/#writing_styles

Falling back to a different writing style would look wrong, especially for the Turoyo authors.

The _madnhaya writing style_ is used for modern East Syriac languages using Swadaya (Aramaic) texts, and in West Syriac texts for headers, titles and subtitles. See https://r12a.github.io/scripts/syriac/#writing_styles

Falling back to a different writing style would reduce the distinctiveness of headings in languages that use West Syriac texts. For text in an Assyrian language it would just look wrong.

Chinese

Different writing styles tend to be applied to different bits of content in the same document to distinguish one feature of the content from another. Remember also that bolding, italicisation and underlining are not native traditions for Chinese, and so font choice is used to distinguish one type of text from another. This is actually a common technique in a number of scripts, not just Chinese. See https://w3c.github.io/clreq/#commonly_used_chinese_typefaces

The _song writing style_ is the most common typeface used in Chinese printing. Song is commonly used in text, headings and annotations. When used in headings, the characters will appear in a bold face, so as to distinguish the heading from the text.

The _kai writing style_ provides calligraphic styles for Chinese characters. It shows notable handwriting features. Kai is mainly used in text that needs to be differentiated from the rest of the content, for example, headlines, references, quotations, and dialogs. (It is rarely used for emphasis, because of its similarity to Song.)

The _hei writing style_, also known as Gothic, is a type style characterized by strokes of even thickness, reduced curves, and a lack of decoration. It is commonly used in headlines, signs, and personal names in dialogs. In body text, characters in Hei style with thicker strokes typically indicate emphasis. Traditionally, publications rarely apply the Hei style for content, but with the growing influence of the World Wide Web and the digital publishing industry, some publications are starting to experiment Hei in this context.

The _fangsong writing style_ lies between Song and Kai. It is commonly used in secondary titles and isolated paragraphs such as quotations or highlighted sentences.

Fallback to a single, arbitrary font is problematic because nullifies the distinctive characteristics of the text to which one of the above writing styles has been applied, for example removing emphasis.

Tamil

Tamil Nadu applied significant orthographic reforms in the latter part of the 20th century. But the orthographic reforms only spread in India and the digital world, whereas Sri Lanka, Singapore, Malaysia, Mauritius, Reunion and other Tamil speaking regions continue to use the traditional syllables. See https://r12a.github.io/scripts/tamil/#writing_styles

Fallback to an arbitrary font may therefore change the regional identity of content and produce an unwelcome orthographic change.

Malayalam also introduced orthographic simplifications in the late 20th century, though there may not be the same geographical split in usage as for Tamil. You can, however, find traditional vs modern fonts. I’m not aware that there are identity-related or practical issues for fallbacks to different fonts, though maybe this is a grey area.

Khmer

See https://r12a.github.io/scripts/khmer/#writing_styles

The _upright writing style_ is used for most modern typefaces (called អក្សរឈរ âksâr chôr).

Fallback to an arbitrary font may not be a major issue, as long as it’s not the mul style, but would be equivalent in principle to blurring the distinction between serif and non-serif fonts in Latin script content.

The _slanted writing style_ (អក្សរជ្រៀង âksâr chriĕng) is used for whole documents or novels. The oblique styling has no effect on the semantics of the text.

Fallback as above, i think.

The _round writing style_ (អក្សរមូល âksâr mul) includes more ligated forms, and is used for titles and headings in Cambodian documents, books, or currency, as well as on shop signs or banners. It may also be used to emphasise important names or nouns.

Fallback to a font of another writing style (which is likely) would remove significant intentional differentiation in the text, including emphasis.

Another style (អក្សរខម ʔk͓sṟkʰm̱), characterised by sharper serifs and angles and retainment of some antique characteristics, is used for yantra text in Cambodia as well as in Thailand.

Tai Tham (Northern Thai (Lanna), Tai Kuhn, ...)

Tai Tham script has 2 main orthographies. One is used for writing the Tai Khün language, and the other for writing the Lanna (or Northern Thai) language. The code points for the letters of each language are mostly, though not always, the same, but the shapes of certain letters vary systematically. (The one Noto font for Tai Tham generally favours glyph shapes associated with Tai Khün, but for some characters with significant differences it uses glyphs more similar to the typical Lanna style. Language tags have no effect.)

The _tai khün writing style_ is used for the Khün language. See https://r12a.github.io/scripts/taitham/#writing_styles

Falling back to a different writing style would affect the identity of the text.

The _lanna writing style_ is used for the Northern Thai (Lanna) language. See https://r12a.github.io/scripts/taitham/#writing_styles

Falling back to a different writing style would affect the identity of the text.

Thai

This is one may be a little more controversial, but essentially it boils down to the idea that glyphs in some Thai fonts have loops and in other fonts they don’t have loops. Loopless is considered to be more contemporary and modern, and is mainly used for advertising and titling. The distinction doesn’t necessarily map to that of serif vs sans – Noto, for example, provides both serif and sans Thai font faces, but they both have loops. On the other hand, Neue Frutiger Thai offers traditional (looped) and modern (loopless) alternatives as part of the same font family (each with both regular and italic substyles). There are, however, a large selection of looped fonts and a large selection of loopless, and it’s likely that replacing a looped font with an unlooped one, or vice versa, significantly changes the tone of the content.
See http://www.fontpad.co.uk/loops-and-latinisation/#more-666
and https://r12a.github.io/scripts/thai/#writing_styles

---

Coming up: my 2p about implementation:

Yes that's a lot more generic styles than we currently have, and i'm sure there are more we would want. But those listed above are pretty standard and useful distinctions in relation to modern text, and as mentioned ignoring those distinctions can degrade the content in terms of identity or function. I also think we could start with the styles we know about and add more as needed. I'd like the generic fallback font system to move away from its current Western stylistic bias, to a more function-oriented tool for dealing with the distinctions that are maintained in the many scripts around the world. I don't think its sensible to try to shoe-horn these needs into the current categories. I think we're looking at a registry of key writing styles, to which lists of fonts can be attached (either by the browser or the user, or both) in browser preferences.

[kidayasuo]

I think it is worth considering adding established typeface categories from each script. This possibility opens up if you accept that generic fonts do not need to match a font.

What is frustrating with a font system is that you need to know names. Say I want to use a rounded sans-serif typeface (or kai or whatever typeface category). What’s in front of me is a long list of font names installed on my platform. Sometimes font names contain their style category but not always. I need to go through names one by one to see which is rounded sans. I found a few and picked up one of them but not very confident if it was the most standard one that I wanted. Anyhow I can now copy the name (which name?) and paste it to my css.

It is really great if I can just say “rounded”. I think the generic font family can be a way to provide a map to the chaos of font names.

Using specific font names has an advantage that you can get the exact style that you know. It at the same time has several disadvantages:

• You need to know which fonts are available on each platform and language that you are dealing with. Finding them can be tricky because fonts on even single platform can vary depending on the package, the region, and the version.
• Minor platforms suffer. Even if they have Kai, for example, unless you know the platform and its font list, it does not exist for the web.
• Platform makers do drop fonts once in a while. This is particularly a problem when you want your pages to live long once after it was created.
• Web pages can’t take advantage of new and better fonts even if they are added to the platform.

[xfq]

I agree with @kidayasuo. Although Web Fonts solved a lot of problems, most of the time we still need a reasonable fallback font, and finding a fallback font by using specific font names is often not that easy for developers (especially when the text is in non-Latin scripts).

[Crissov]

Even for the “Latin” script – some scholars prefer the term _roman script_ – there are several styles, variants or hands that have very distinct connotations (which may vary by context of course), although their strong local preference is almost gone, e.g. blackletter, uncial and insular for copyist and (early) letterpress texts.

The look of fonts that fake handwriting very much depends on the simulated writing utensil and surface in all scripts. (The predominant medium informed a lot of glyph evolution.) This may be another kind of abstraction to derive generics from.

[kojiishi]

@faceless2

If the aim is to be consistent - adding "fangsong" or "nastaliq" just because we added "serif" - then we're going to be adding a lot of them.

I think the aim is to provide fair opportunities to all scripts, because that is our obligation as a standard body. And you're right, by accepting "fangsong" and "nastaliq", we will have to add a lot.

I think what we need to figure out here is a mechanism to make it maintainable and implementable. We cannot add all requests blindly, so we will need criteria. The all characteristics of Generic font families as today is not cheap to implement (at least for us) so we might want a lighter mechanism. Maybe a registry works better than putting all of them into the spec, as we do for counter-styles. Maybe it's nice to make it polyfill-able.

Maybe there are more, but I think you raised a very good point. The aim, and how we want to approach to this problem, assuming there will be a lot, is probably the first thing we would like to figure out.

[faceless2]

@kojiishi

Actually I think I was swimming well out of my depth on internationalization, but thank you anyway. While I can't see a use for fantasy and emoji, if the consensus is that others need to be added, then putting them in a registry that can be maintained by those with the expertise - a group which safely excludes me - is an excellent idea.

@font-face-generic {
    font-family-generic: kaiti;
    src: local("DFKai-SB"), local("Kaiti SC"), ...
}

The counter-styles registry works so well, it's also how I imagine a solution (although limited to user-agent stylesheets, of course). Thanks to that list there's been almost no debate on the need, or otherwise, to support a counter variant, because doing so is virtually zero cost. It would be a huge win to get to that point with generic fonts.

[kojiishi]

@faceless2

Actually I think I was...

Sorry if my wording looked to mean you're not, I agree you're doing more than great and I really appreciate it. I just wanted to say that the aim in my mind was slightly different from yours.

[AmeliaBR]

One thing I don't see mentioned here is that every new generic font keyword is a breaking change.

Font family names have never needed to be quoted, which means the parser doesn't have any way to distinguish a generic keyword from a family name.

Per the font matching algorithm is currently defined, font-family: script; will look for:

• first, an @font-face rule with a font-family: blackletter descriptor
• failing that, a font named “blackletter” installed on my computer.

If we add a blackletter generic, both of those would be overridden by the new generic mapping.

Now, most systems won't have installed fonts that match a simple keyword name, but some internal / controlled systems will. And it is much more common to use simple keywords to describe your own web fonts.

[kojiishi]

@AmeliaBR

One thing I don't see mentioned here is that every new generic font keyword is a breaking change.

Good point. for this new set of generic font families, I think we should change this override behavior.

[jfkthame]

One thing I don't see mentioned here is that every new generic font keyword is a breaking change.

Font family names have never needed to be quoted, which means the parser doesn't have any way to distinguish a generic keyword from a family name.

This is indeed an issue that needs to be taken seriously, I think. The addition of fangsong was already such a breaking change, given that there may very well be a font family named "FangSong" (e.g. on Windows).

(An author could previously have written font-family: fangsong, fallbackFontName in the expectation that on Windows, where the font "FangSong" is installed, it would be used, and on another platform the fallback would be used; but once fangsong is recognized as a generic, the behavior changes depending on what mapping the UA provides for the generic name.)

Maybe any new generics should be handled via some other syntax, such as font-family: generic(<name>), to minimize the risk of disrupting legacy content. It would then be possible to extend the set of supported generic <name>s without conflicting with actual font names.

[r12a]

Maybe any new generics should be handled via some other syntax, such as font-family: generic(), to minimize the risk of disrupting legacy content. It would then be possible to extend the set of supported generic s without conflicting with actual font names.

I was thinking along similar lines.

Another possibility may (??) be a prefix character that creates a name one is unlikely to see for naming fonts, eg. -fangsong, ~fangsong, :fangsong, _fangsong, etc. (those may not be good examples, but they show what i mean).

[jfkthame]

IMO a function-like syntax would be much clearer than some kind of prefix; it also nicely parallels var(...) and env(...).

(I wonder if we should have done a ui(...) function instead of all the ui-* generics, too. But I guess that ship may have sailed, given that I believe at least Safari has shipped them.)

[svgeesus]

If the correct answer is the latter, PANOSE could probably still inform new generics to add.

Panose-1 is totally Latin-centric.

There was an attempt to start standardizing Panose-2 in the early days of W3C, but that faltered.

[css-meeting-bot]

The CSS Working Group just discussed generic fonts.

The full IRC log of that discussion

<TabAtkins> Topic: generic fonts

<astearns> github: https://github.com/w3c/csswg-drafts/issues/4910

<TabAtkins> chris: Myles started a wiki for criteria for new generic fonts

<TabAtkins> chris: I changed that to "what are generic fonts for"

<astearns> https://wiki.csswg.org/spec/css-fonts

<TabAtkins> chris: STarted in a very different, latin-centric CSS1 world

<TabAtkins> chris: Where we didn't know what fonts were avaiblable, etc

<TabAtkins> chris: Need to revisit

<TabAtkins> chris: Bunch of issues about generic fonts, but unitl we decide what they're for, we can't progress

<TabAtkins> chris: One answer is w etake an axe to them

<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

<TabAtkins> chris: Fine with either solution, but we need to decide and not get a mix

<r12a> q+

<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

<r12a> Meet won't recognise my mic

<fantasai> r12a, dial in

<fantasai> r12a, https://lists.w3.org/Archives/Member/w3c-css-wg/2020AprJun/0066.html

<TabAtkins> r12a: So chris outlined two possible routes.

<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"

<TabAtkins> r12a: So the thir doption is to deprecate non-generic local fonts entirely

<TabAtkins> r12a: Currently the generics are very western-centric, and people can't decide whether they're about style or substance

<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

<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.

<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.

<TabAtkins> r12a: Big concern is that people could think up zillions of different types of fonts.

<TabAtkins> r12a: I see a gap for i18n

<TabAtkins> r12a: For just a few things, not a huge number

<TabAtkins> r12a: The things I listed in the thread are pretty fundamental to users of those scripts

<TabAtkins> myles: I'm sympathetic to Kida's argument

<TabAtkins> myles: Scrapping all generics seems like the wrong direction

<xfq_> r12a's list -> https://github.com/w3c/csswg-drafts/issues/4910#issuecomment-619342561

<TabAtkins> myles: Content lbockers commonly disallow all webfonts

<TabAtkins> myles: So it would be cool for sites without webfonts to stil lhave some control

<TabAtkins> myles: So let's not delete the entire generic feature

<TabAtkins> chris: Fair

<Rossen_> q?

<TabAtkins> chris: Another thing that hasn't come up yet is, to what extent is this mapping from teh browser, vs from the user?

<TabAtkins> myles: Let's say we gathered this evidence, what woudl tha tinform?

<TabAtkins> chris: If the brower, we need a registry saying what types of fonts map to each generic.

<TabAtkins> chris: Otherwise we just describe what they do, and the user chooses.

<TabAtkins> chris: But most users don't customize, so I'd be wary of that solution.

<TabAtkins> myles: Right, the spec right now has some examples and descriptions.

<xfq_> Should we start a registry for additional generic fonts? -> https://github.com/w3c/csswg-drafts/issues/4566

<TabAtkins> myles: I think that's sufficient, and we don't need a registry of specific fonts.

<stantonm> q+

<r12a> q+

<xfq_> ack fantasai

<atsushi> q

<atsushi> q+

<TabAtkins> fantasai: I think Richard's point about fonts used for differentation, simialr to latin italics, is a really important point.

<TabAtkins> fantasai: We need to solve that problem for all the writing system that need it.

<florian> q+

<TabAtkins> fantasai: Whether thru generics or whatever, there just needs to be controls for that kidn of differentiation.

<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

<chris> good point that this could be done by new font-style values

<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.

<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.

<TabAtkins> fantasai: So we mainly need to hit where a document uses the same type of text in two or more styles.

<TabAtkins> myles: When you have a single element with two different langs, and you style it with a single generic...

<TabAtkins> myles: If we want generics to have a meaning across langs, they need to be similar

<TabAtkins> myles: So like 'sans-serif' with an arabic character inside, it would need to have a reasonable "sans-serif-ish" font for arabic

<TabAtkins> myles: So it makes sense to overload the term and use it for various writing systems.

<TabAtkins> myles: But in Richard's list, I don't see much overlap.

<TabAtkins> myles: So don't think we can come up with one token that works across those writing systems.

<florian> q?

<TabAtkins> fantasai: I think you're addressing a different point.

<fantasai> https://wiki.csswg.org/spec/css-fonts

<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.

<TabAtkins> fantasai: Otherwise I'd say that's a good test.

<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.

<TabAtkins> myles: About the preinstalled vs not, the reason I picked that term is that it's clearly testable.

<TabAtkins> myles: You can point to an OS that has it.

<TabAtkins> myles: The vaguer it gets, the harder it is to test.

<TabAtkins> myles: Hopefully we can come up with a more general term that's still testable.

<Rossen_> ack dbaron

<chris> +1 to testability

<TabAtkins> dbaron: We've had some discussion about "does the user choose" vs "does the browser choose"

<TabAtkins> dbaron: In a rough approximation, users don't configure their browsers, so we shouldn't depend on that.

<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.

<TabAtkins> dbaron: Third option tho is that the font designer chooses.

<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.

<TabAtkins> dbaron: Something we could design towards in the long run even if it doesn't work in the shor trun.

<TabAtkins> dbaron: "Browser chooses" has more power on some systems, where the browser vs OS has more control over installed fonts.

<TabAtkins> dbaron: On Mac you can make stronger assumptions than on Linux or Android

<TabAtkins> dbaron: On a different topic, another questiona bout generics is, is it meaningful to fall back past a generic?

<TabAtkins> dbaron: In CSS2 it was not meaningful to fall back past serif, etc, because there wasn't anything else.

<TabAtkins> dbaron: But we could think of generics as covering part of the character space, that could still trigger fallback.

<TabAtkins> chris: We did change to allow that

<TabAtkins> myles: We changed it to match browsers in fact; the names are just aliases, so fallback can happen normally.

<TabAtkins> myles: I think that makes sense with my earlier point about the proposed new names not being generic.

<TabAtkins> myles: Best way to handle writing-system-specific names is to allow the browser to fall past sans-serif and hit nastaliq, etc.

<TabAtkins> florian: Same with say "nastaliq" on Japanese.

<TabAtkins> chris: We can close a lot of issues of "how to match X on Y" with "it doesn't"

<xfq_> ack stantonm

<faceless2_> +1 to allowing fallthrough, solves lots of problems.

<TabAtkins> stantonm: Use-case of ebooks too.

<TabAtkins> stantonm: Licensing structure for shipping fonts on ebooks is... hard. Often charge per copy, cost prohibitive.

<TabAtkins> stantonm: So a lot of people wnat to use generics.

<TabAtkins> stantonm: That way they can get around these licensing issues but still have interesting styles in their books.

<dauwhe> q?

<xfq_> ack r12a

<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

<TabAtkins> r12a: I think it's equally important to the toher things she mentioned, matching content to the right font

<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

<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.

<TabAtkins> r12a: So that could prevent these langauge sfrom being equal partners on the web.

<TabAtkins> r12a: So in the thread I was playing with the idea of users making the assignment of installed fonts to generic names.

<TabAtkins> r12a: I take the point tha tusers dont' mess with prefs much

<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

<TabAtkins> r12a: So I think we shoudln't deny users the ability to make that association.

<xfq_> s/[missed]/kano/

<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.

<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.

<TabAtkins> fantasai: Shoudln't require the author to specify a new keywords.

<TabAtkins> r12a: My concern is that people developing browsers dont' understand the reqs to make that work.

<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.

<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.

<dbaron> s/nasq/Naskh/

<AmeliaBR> +1 to using names that are actually relevant to the writing system

<atsushi> yes

<faceless2_> q+

<fantasai> s/a new keywords/a new keyword, should be built into the way generics behave generally/

<xfq_> ack atsushi

<fantasai> s/in Country B/in Language B/

<TabAtkins> atsushi: Calling from i18n wg

<TabAtkins> atsushi: So for CJK fonts, quite a drudge to make it available via webfonts

<TabAtkins> atsushi: Similar generic fonts already in OSes

<Rossen_> Zakim, close queue

<Zakim> ok, Rossen_, the speaker queue is closed

<fantasai> s/webfonts/webfonts, particularly since they can be many megabytes in size/

<TabAtkins> atsushi: So defining generics for CJK could help webdevs a lot.

<myles> q+ to talk about streamable fonts

<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.

<xfq_> ack fl

<TabAtkins> florian: I don't have a strong view as to *how to address the identity question, but agree it's very important

<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.

<TabAtkins> florian: So about "what if there's only one font"? In that case you can use it by name.

<TabAtkins> florian: And when there are multiples, we can come up with a genric name as needed.

<Rossen_> q?

<TabAtkins> florian: So we could come up with an at-rule that lets authors specify a font that can get overridden by UAs later

<TabAtkins> myles: That's just a @font-face with a local() source, right?

<TabAtkins> florian: Hm, if there's no real parsing differences, maybe

<TabAtkins> fantasai: What about blockign local fonts? Then it wouldn't work

<TabAtkins> myles: STill discussing balance of privacy vs minority fonts, yeah

<TabAtkins> florian: Also, letting fonts decide which category they go in - what if it matches multiple categories? Which doyou pick?

<chris> q?

<Rossen_> ack fantasai

<xfq_> ack fa

<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

<TabAtkins> faceless2_: I'm a big fan of the counter-styles registry, for exaqmple

<TabAtkins> faceless2_: Wondering about the interaction there

<TabAtkins> fantasai: myles, you said you were against a registry

<TabAtkins> myles: No registry can cover every OS/browser combo.

<TabAtkins> s/fantasai/faceless2_ /

<TabAtkins> faceless2_: Sure, but our groups could maintain that.

<TabAtkins> myles: OSes change yearly, who's gonna maintain that?

<r12a> for clarity: I was talking about a registry for generic names, but not for assigning fonts to those generic names

<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"

<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.

<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"

<faceless2_> s/our groups/interested groups/

<TabAtkins> myles: Quick mention - atsushi mentioned CjK fonts in particular can be big

<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.

<TabAtkins> myles: Some early exploration suggests this is orders-of-magnitude speedup.

<r12a> (there are also pages like this https://r12a.github.io/scripts/phrases that would involve downloading LOTS of fonts to display)

<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

<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

<AmeliaBR> ScribeNick: Amelia

<AmeliaBR> ScribeNick: AmeliaBR

[Crissov]

There are 2 notations, i.e. quoted string and plain keyword, for 3 namespaces, i.e. @font-face, installed typeface and generic font family names, but the latter cannot clash with the others when they are in quoted strings. For precedence rules, the different notations are currently not distinguished, though.

• W3C/specification-defined, global generic font family names _must not_ be quoted
• vendor/platform-defined, external local typeface names _should_ be quoted – ideally change to _must_
• author/stylesheet-defined, internal custom font face names _may_(?) be quoted

Perhaps, this

~~ ebnf
<'font-family'>: [  |  ]#
~~

could be changed to this

~~ ebnf
<'font-family'>: [ |   ]#;
: | " ";
~~

Perhaps, font-family: "foo" could imply @font-face {font-family: "foo"; src: local(foo)} and font-family: foo could imply @font-face {font-family: foo; src: generic(foo), local(foo)}.

[tabatkins]

I highly doubt we can change font-family parsing or interpretation to distinguish string vs keyword at this point. It's been in place for many, many years, and it's very likely that pages depend on it.

[r12a]

I think we're looking at a registry of key writing styles, to which lists of fonts can be attached (either by the browser or the user, or both) in browser preferences.

Remarks in a couple of recent conversations made me think that i should be a little more clear about what i had in mind here.

[1] I envisaged a registry of generic font names, but _not_ a registry that maps specific fonts to those names. (Although browsers may want to map a default font to the name.)

[2] The mechanism for users to assign a preferred font on their system to a given generic font name would either be like or be an extension of the mechanism currently available to users of Gecko and Blink browsers for picking preferred fonts for a particular language. See the picture below of my settings on Firefox for Latin text.

[Lorp]

The generic concept always seemed to me like the first step of a versatile font selection mechanism. I believe the ability to request (not supply) a font with certain characteristics would be very useful. These requests seem reasonable:

• a sans-serif font that supports weights: 100, 200, 400, 700, 900
• a serif font that explicitly supports optical size: 8, 12, 16
• a font that supports specific languages or characters (this would help authors avoid the problem of a fallback font interrupting the text to supply characters missing from fonts earlier in the stack)
• a font named “Baskerville” that supports polytonic Greek

Using a function-like syntax we could construct selection requests such as:

• select(style=sans-serif; weight-range=100,200,400,700,900)
• select(style=serif; optical-size-range=8,12,16)
• select(font-family=Baskerville; lang=el; characters=Ἕἧ)

Failure to match a request would mean fallback occurs.

The unpredictability of such a system with a large number of fonts installed might be problematic, though if implemented in a browser (e.g. Safari) that disallows user-installed fonts, the risk of obtaining an unsuitable font can be contained at reasonable cost.

[fantasai]

I wanted to illustrate some of the discussion around the need for font distinctions to ”distinguish some content from other content (semantics)”, as @r12a puts it. I know I've used the analogy of how Latin sometimes uses italics or obliques to represent an “alternate voice”, a semantic distinction that would be lost if everything fell back to the same font. Here are some illustrations of similar usages in non-Latin writing systems:

• http://fantasai.inkedblade.net/style/scans/ChinatownSFPL014.png
• http://fantasai.inkedblade.net/style/scans/ChinatownSFPL037.png
• http://fantasai.inkedblade.net/style/scans/LoC111.png
• http://fantasai.inkedblade.net/style/scans/Princeton%20East%20Asian%20Library%20-%20ISSN1228-3436%20002.png
• (compare to obliques, used in http://fantasai.inkedblade.net/style/scans/Princeton%20East%20Asian%20Library%20-%20ISSN1228-3436%20001.png )
• http://fantasai.inkedblade.net/style/scans/Princeton%20East%20Asian%20Library%20-%20ZhongGuoYin__Xue%202005.4%20001.png

I have not noticed such usage in Japanese fwiw, but in Chinese it seems fairly common. I think it's important for us to represent such common and typical semantic differentiations in CSS generically. Whether we do so through generic font families, font-style, or some other mechanism, it doesn't matter. But it needs to be possible for a document without access to downloadable fonts to be able to make such necessary distinctions.

[kojiishi]

I have not noticed such usage in Japanese fwiw, but in Chinese...

It is common in Japanese too. I think it is a general requirement to style an "alternate voice" in different fonts, and italics/oblique don't work well in Japanese either. Which one to use instead isn't very well standardized, vary by the author and the situation, but usually a specific group of families that represents the author's intention best, such as serif/sans-serif, rounded, Kaisho, Reishotai, Kointai, (the last three examples are Japanese specific families) etc.

[nigelmegitt]

Additional data point: In subtitles and captions various mechanisms are used to indicate alternate voices, including:

• Use of capitals vs normal case
• Change of colour (colour recycling algorithms are not totally straightforward - think "4 colour map problem")
• A text label

It's considerably less common to use a change of font, in today's typical usage, but could be adopted in the future, potentially.

[xfq]

I have not noticed such usage in Japanese fwiw, but in Chinese...

It is common in Japanese too. I think it is a general requirement to style an "alternate voice" in different fonts, and italics/oblique don't work well in Japanese either. Which one to use instead isn't very well standardized, vary by the author and the situation, but usually a specific group of families that represents the author's intention best, such as serif/sans-serif, rounded, Kaisho, Reishotai, Kointai, (the last three examples are Japanese specific families) etc.

As an example, Japanese Gothic typefaces are often used for highlighting/emphasis when the main text is in a Mincho typeface. This usage is documented in jlreq (see also https://tsutawarudesign.com/miyasuku/miyasuku-56.svg for an illustration).

(I will refrain from giving more examples. I think examples are more suitable for issues for specific generic font families, rather than this meta issue.)