search

w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.42k stars 652 forks source link

[meta] [css-fonts] Criteria for generic font families #4910

Open litherum opened 4 years ago

litherum commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

FWIW, I have changed the wiki page to use the more fuzzy term platform instead of operating system.

aphillips commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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.

litherum commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

fred-wang commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.

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

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 commented 4 years ago

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:

xfq commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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:

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.

Perhaps, this 

<'font-family'>: [ <family-name> | <generic-family> ]#

could be changed to this

<'font-family'>: [ <typeface> | <generic-family>  ]#;
<typeface>: <family-name> | " <family-name> ";

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 commented 4 years ago

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 commented 4 years ago

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.

Screenshot 2020-04-30 at 16 44 17

Lorp commented 4 years ago

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.

fantasai commented 4 years ago

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, 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 commented 4 years ago

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 commented 4 years ago

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.

xfq commented 4 years ago

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

Myndex commented 2 years ago

Generic Font Fallbacks for Accessibility and More

Hello everyone, I'm going to start with a response to something Chris @svgeesus mentioned above:

Do generics make sense in a world where downloadable fonts are the norm and generics merely influence fallback?...SNIP... I feel that we can't reasonably define the existing generics or indeed extend them, without clarity on their purpose.

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 Categories

But 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 Set

A 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 Fonts

On 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 core

If 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:

Font Size Compared

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

css-meeting-bot commented 2 years ago

The CSS Working Group just discussed generic font families.

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/w3c/csswg-drafts/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
r12a commented 10 months ago

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.

Does that help? cc @svgeesus @frivoal

xfq commented 10 months ago

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 https://github.com/w3c/csswg-drafts/issues/4605

'DengXian' should be listed under 'Hei', instead of 'Other'.

Crissov commented 10 months ago

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 Geok (Khutsuri = Asomtavruli + Nuskhuri) and Geor (Mkhedruli + Mtavruli).

Crissov commented 10 months ago

PS: Maybe the best solution for better fallbacks of downloadable web fonts is not adding more generic values to the font-family property but adding informative descriptors to the @font-face at-rule, which would help browsers to choose an appropriate local fallback.

litherum commented 10 months ago

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.

Crissov commented 9 months ago

You’re right, there is no such fallback mechanism based on descriptors yet. Therefore, it would be a less severe change to add generic() to the src descriptor, working much like local().