[meta] [css-fonts] Criteria for generic font families #4910
Comments
xfq
added
the
i18n-tracker
|
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 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 #4055 / #4497 turn out, this may interact/overlap with that. |
|
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.” |
|
FWIW, I have changed the wiki page to use the more fuzzy term platform instead of operating system. |
|
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 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. |
|
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)? |
|
@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 |
|
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.
The following would pass the first but not the second criterion:
Iʼm not proposing any of these here. I just think it would heron to know what the actual goal is. |
|
@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:
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. |
|
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? |
|
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. |
|
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 |
|
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! |
And we might then consider deprecating those generics. Or not.
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! |
|
Just for the record, |
Thatʼs both a good and important question. If the correct answer is the latter, PANOSE could probably still inform new generics to add. |
|
Anyone specifying 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. |
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. |
|
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. |
Although I don't have an answer now, in #4442 (comment) we resolved that only |
|
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/fuf#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/nqo#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. (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/arb#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/ur#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. ChineseDifferent 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. TamilTamil 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. KhmerSee https://r12a.github.io/scripts/khmer/km#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. ThaiThis 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. 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. |
|
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:
|
|
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). |
|
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. |
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. |
|
There are 2 notations, i.e. quoted string and plain keyword, for 3 namespaces, i.e.
Perhaps, this <'font-family'>: [ <family-name> | <generic-family> ]#could be changed to this <'font-family'>: [ <typeface> | <generic-family> ]#;
<typeface>: <family-name> | " <family-name> ";Perhaps, |
|
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. |
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.
|
|
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:
Using a function-like syntax we could construct selection requests such as:
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. |
|
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:
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, |
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. |
|
Additional data point: In subtitles and captions various mechanisms are used to indicate alternate voices, including:
It's considerably less common to use a change of font, in today's typical usage, but could be adopted in the future, potentially. |
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.) |
Generic Font Fallbacks for Accessibility and MoreHello everyone, I'm going to start with a response to something Chris @svgeesus mentioned above:
While downloadable fonts were a boon to designers, downloadable fonts are also responsible for many of the problems of visual accessibility of web content today. As you know I am immersed in researching solutions for these problems. In thinking about this topic, it is an opportunity to address font related accessibility issues. I do think it would be good to specify some very standard fallbacks, but those fallback fonts should be ones that are also accessible. This provides a utility of purpose and defined need for defining and extending the existing generic font types. At the moment, the common generics "Arial" and "Times New Roman" are not accessible-friendly. If we look at the old "MS core web fonts", the two most accessible are those designed by Matthew Carter, "Verdana" and "Georgia". Even so, some tweaks could be added to a few glyphs with a eye to improve accessibility. I'm not certain the license situation on those two, not just regarding redistribution but also for creating derived forms for extended language sets and for adding accessibility attributes. Nevertheless, Ideally the generics would be actual, specific fonts to improve cross platform compatibility. There are however a number of open-source fonts where we could modify as needed for accessible versions to be the generic fallbacks for when a specified font is not available. Of course this raises questions regarding other languages. Reasons and CategoriesBut some good reasons for defining a specific font family for each generic name/type:
If those are the reasons, and we want to help content creators maintain some consistency while achieving these goals, then I'd suggest the following as a starting group of font classifications. Basic Font SetA useful minimum set of generic fonts. Content and Body Text
For Display/Headlines/Spot Reading Elements only:
Monospaced
Special
Bonus, the "Non-Accessible" styles people like to use: Some of these might have use for headlines, but shouldn't be used for body text that is meant to actually be read. But then should fonts like "fantasy" be a part of the generic font set at all? Once we get into this subgroup of fonts, generic fallbacks become less useful, whereas the generics above are all very useful.
Regarding Accessible FontsOn this point, I am not talking about fonts as far as their aesthetic design. I am talking strictly about accessibility, including research on dyslexia, cognitive, contrast perception, and visual impairments. Some accessibility points are: does a given font...
Most of these characteristics are discussed prominently in the current research into readability. For cites, I refer to Lovie-Kitchin, Bailey, Arditi, Legge all of whom have done the bulk of the work in readability research for normal and impaired vision. ...to the coreIf we consider the "MS core web fonts" which MS distributed once upon a time, namely the proprietary fonts Andalé Mono, Arial, Arial Black, Comic Sans MS, Courier New, Georgia, Impact, Times New Roman, Trebuchet MS, Verdana and Webdings, Of THAT group, only Georgia and Verdana are really accessible friendly, and perhaps Andale Mono with reservations. But what about Trebuchet ? The problem with Trebuchet is the default track/kerning is too tight, so it's not normally on my list of "good" fonts for accessibility. Also of that group, Courier New is nothing short of an unusable illegitimate version of the classic Courier typeface. Arial is nothing but a pure copy of Helvetica, which I also give somewhat low marks to regarding accessibility. Times New Roman with its small size and small x-height make it less than desirable for web use (The small size of Times made it a choice for newspapers who were concerned with jamming as much text into as small a space as possible). On this point, there is another pressing issue in terms of web content and that is the very non-standard nature of font metrics. Font size and font weight are not consistent to the point of being irrelevant across different families, even within the same foundry. Examples:
Real Courier is a fairly readable font, but the MS commissioned Courier New is so very light it is unusable. Times New Roman renders smaller than many other fonts for a given font-size. While newspapers try to save paper, this is an accessibility problem and there is no "paper" to save on the web. I do have proposal I am preparing to address parts of the size problem, which I'll post soon. Also for the record, my critique on some fonts is only and exclusively directed at accessibility issues of the cited fonts. I have a brief informal review of accessibility in fonts with many examples and some discussion that is related to this issue. TL;DR
Thank you, Andy |
|
The CSS Working Group just discussed The full IRC log of that discussion<TabAtkins> Topic: generic font families<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. <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. <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. <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 <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. <xfq> GitHub: https://github.com//issues/4910 <astearns> zakim, open queue <Zakim> ok, astearns, the speaker queue is open <myles> q+ <chris> q+ <astearns> ack myles <TabAtkins> q+ astearns <TabAtkins> myles: I hadn't seen this before, interesting <TabAtkins> myles: You mentioned a user-created generic font family <TabAtkins> myles: Are you describing that a user could make a font-family named "myles" and a website coudl use it? <TabAtkins> myles: Or that the generic families are still defined in CSS, but users control what fonts map to the family <Peter> q+ <TabAtkins> r12a: Yes, one of those. More details need to be worked thru. <TabAtkins> r12a: Discussion about english-specific details of the existing generic fonts <TabAtkins> r12a: But having a registry could be slower, but would give us control over what's available <TabAtkins> r12a: There's lots of different styles for non-latin scripts <astearns> ack chris <TabAtkins> r12a: But the main thing is I want a mechanism where a user can control which fonts belong to which category <TabAtkins> chris: So there's two ways we can do it with generics <r12a> q+ <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. <TabAtkins> chris: The other way is to have a whole bunch of categories which don't map to anything for many scripts <florian> q+ <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" <TabAtkins> chris: I think the "thousand flowers" approach is where to go, we just need to be clear about it <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 <chris> qq+ <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 <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 <astearns> ack chris <Zakim> chris, you wanted to react to chris <astearns> ack astearns <myles> +1 to what Peter is saying <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? <TabAtkins> Peter: Having the user be able to associate fonts with a generic family does help with another issue on the list <TabAtkins> Peter: Relatively small communities get a preferred font on their system <TabAtkins> Peter: And if it's something the browser uses but doesn't expose tot he content, that addresses the privacy/fingerprinting concerns <astearns> ack Peter <TabAtkins> Peter: If we have a thousand generic families, that seems like a mess <TabAtkins> Peter: Even in western-centric families, they quickly fail <TabAtkins> Peter: Type doesn't fit nicely into categories <TabAtkins> Peter: So you ahve an issue - what does the author consider a 'fantasy' font vs the end-user, and are they agreeing? <chris> fantasy should be deprecated honestly <astearns> namespace problems could be solved by using functional notation: generic-font(myles) <myles> q+ <TabAtkins> Peter: If the user goes to a site do they expect their font to be used on a given author's site? <astearns> zakim, close queue <Zakim> ok, astearns, the speaker queue is closed <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 <TabAtkins> r12a: Like for nastaliq, Urdu speakers really don't want a nasq (sp?) font, they always want nastaliq <TabAtkins> r12a: So I think those users need a way to define what happens when a particular writing style is used <astearns> ack r12a <astearns> ack fl <TabAtkins> florian: I think a few of the problems aren't taht bad <xfq> s/nasq (sp?)/naskh/ <TabAtkins> florian: If the list is populated by users it would be confusing - extensions could potentially expand for them <TabAtkins> florian: If we have a bunch of UA information - a browser on Mac knows what fonts the system ships with, they cna prepopulate <TabAtkins> florian: But for the registry, we can graduate to official only if at least one browser wants to ship with a default assignment <TabAtkins> florian: So then authors have a list of known groups, and users/UAs can add more <TabAtkins> florian: So yes, there are many, but only supported ones hit the registry <TabAtkins> florian: For the name clash, we can just namespace into a function if we need to <chris> yes, I like the idea of a generic() function <astearns> ack myles <TabAtkins> myles: This is a meta-issue that's been going on for over a year, lots of comments and participants <TabAtkins> myles: Often when CSSWG discusses meta-issues there are opinions bu tnot much issues <r12a> q+ <TabAtkins> myles: Maybe we want to say "no policy, but we'll discuss individual requests as they come" and close the issue? <TabAtkins> r12a: That's sort of avoiding the problem <TabAtkins> r12a: We think users need a solution <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 <TabAtkins> astearns: This issue isa bout the principle, and was started in part to *shut down* dicussino of new generics <TabAtkins> astearns: Think it makes sense to have an issue about how to have new generics <chris> r12a should put an I18n-needs-resolution label on 4910 in that case <TabAtkins> fantasai: I dont' think it's a good idea to have user-defined generics, makes more sense to ahve them in the spec <TabAtkins> fantasai: Need to be more open to ahving generics because there are a lot more necessary <TabAtkins> fantasai: richard brought up a point about users wanting a certain style of font over another <astearns> I think the idea of having user tweaking of UA-defined generics is really interesting <TabAtkins> fantasai: That shoudl be handled in user settings by setting the generics to the appropriate style <TabAtkins> fantasai: That doesn't need a new generic <TabAtkins> fantasai: When it is needed is when a variant conveys meaning <TabAtkins> fantasai: Like in english using italics for emphasis. Those are shifts in the family but it's not really a different shape. <TabAtkins> fantasai: [missed] <TabAtkins> fantasai: Those kidns of things describe a shift <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 <TabAtkins> fantasai: So we need generics for those cases at a minimum <TabAtkins> fantasai: Maybe for more reasons, like our recent 'rounded', which can be done case-by-case <TabAtkins> fantasai: But we need to be more open to generics that only have meaning for some scripts <r12a> international users use specific font categories of font to change the font style where we might use bold or italic in English <TabAtkins> fantasai: While trying to have them be as broad of a range as possible <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 <chris> I volunteer to raise the new issue on adding generics <TabAtkins> astearns: Not this meta issue about whether to do it at all <TabAtkins> astearns: We didn't get to the user-installed fonts issues <TabAtkins> astearns: But we have a longer-form meeting scheduled next week <chris> yay! <TabAtkins> astearns: We could invite you at a scheduled time block <TabAtkins> astearns: I'll contact you about that |
|
I recently updated my Font Lister page, which lists fonts available on macOS and Windows11 platforms, plus Noto fonts, and SIL fonts. There are over 800 fonts for 154 Unicode scripts. Those pages group fonts into categories, which i tried to align with potential generic font names. The result of that is described in the wiki page Generic font families. I came up with a proposed set of initial generic font names to cover all those pre-installed and Noto/SIL fonts. |
|
Some preliminary observations about the font lister: Traditional Chinese also has Fangsong fonts, but they don't come with (at least Apple) operating systems. Japanese also has Fangsong fonts (like this one), but they don't come with the operating system either. 'Rounded' is not only for Japanese. Simplified and Traditional Chinese also have rounded typefaces, like:
See also #4605 'DengXian' should be listed under 'Hei', instead of 'Other'. |
|
If a script has multiple ISO 15924 codes which can be identified as typographic variants of each other and are not encoded separately in Unicode, I would expect them to be accessible as a generic font family, regardless of default support in operating systems. This includes:
Not sure about Georgian |
|
PS: Maybe the best solution for better fallbacks of downloadable web fonts is not adding more generic values to the |
|
I don’t think that makes sense. If the font in an @font-face rule cannot be used for whatever reason (can’t be downloaded, doesn’t support the character, etc.) then the @font-face block is skipped and the next entry in the font-family list is used. There is no such thing (as far as I’m aware) as an @font-face local fallback, that is specific to a particular @font-face block, to be used when the desired font from the @font-face block can’t be used. |
|
You’re right, there is no such fallback mechanism based on descriptors yet. Therefore, it would be a less severe change to add |
Fixed. |
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.
I put this on a wiki page in accordance with #4606 (comment) where we resolve for me to start a wiki, and whatever we decide will be edited into that wiki page.
The text was updated successfully, but these errors were encountered: