Open litherum opened 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.
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 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.
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 fantasy
if we were able to re-evaluate current generic font families.
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.
serif
serif
, conservativeserif
sans-serif
, modernsans-serif
monospaced
)cursive
)
The following would pass the first but not the second criterion:
fantasy
) 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 Agenda+ F2F
.
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!
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!
Issues (some closed) whose resolution could be informed by this meta-issue:
monospace
and ui-monospaced
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.
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.
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.
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.
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.
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.
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.
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.
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 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 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.
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 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.
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 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.
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.
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.
@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.
@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.
@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.
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:
@font-face
rule with a font-family: blackletter
descriptorIf 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.
@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.
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.
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).
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.)
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.
The CSS Working Group just discussed generic fonts
.
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)}
.
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.
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.
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:
select(style=sans-serif; weight-range=100,200,400,700,900)
select(style=serif; optical-size-range=8,12,16)
select(font-family=Baskerville; lang=el; characters=Ἕἧ)
Failure to match a request would mean fallback occurs.
The unpredictability of such a system with a large number of fonts installed might be problematic, though if implemented in a browser (e.g. Safari) that disallows user-installed fonts, the risk of obtaining an unsuitable font can be contained at reasonable cost.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
I believe we should have defined generics that also serve as fallbacks for accessibility.
These generic fallbacks would also serve as the "reference" fonts for WCAG guidelines for defining example size and weight characteristics.
These generic fallbacks would also provide a useful substitute when a user agent was unable to load a specified font. This is a common enough occurrence that should not be overlooked in terms of a reliable need for generics.
Thank you,
Andy
The CSS Working Group just discussed generic font families
.
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
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'.
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:
Arab
:
Aran
, mentioned in i18n-discuss as nastaliq
alongside ruqa
and kufi
Cyrl
:
Cyrs
Egyp
:
Egyd
Egyh
Latn
:
Latf
or blackletter in generalLatg
or insular uncialSyrc
, all recognized in i18n-discuss:
Syre
as syriac-estrangelo
Syrj
as syriac-western
Syrn
as syriac-eastern
Not sure about Georgian Geok
(Khutsuri = Asomtavruli + Nuskhuri) and Geor
(Mkhedruli + Mtavruli).
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.
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 generic()
to the src
descriptor, working much like local()
.
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 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.