[css-fonts] Allow authors to redefine generic font families

[LeaVerou]

Background

Most websites define their own typography, yet currently UI components have no access to it. In many cases using the inherited font-family is ok, but for others it’s not. Examples:

• Badges. A badge should never use serif text, yet a component using a badge may be used in a place where the inherited font is the serif one (e.g. if it’s used for body text.
• Monospace font, for code snippets, examples, etc.

We recently got access to the OS’s default font families (ui-*, system-ui) which provide far better alternatives than the generic counterparts, and are in very widespread use. However, web pages typically define their own sans, serif, monospace, etc. fonts, and any UI library or component used within the page should have access to these, not just the OS defaults.

This is part of a much broader problem around pages exposing their design tokens, but inspired from #9660 I figured maybe instead of trying to define a more general feature, paving the cowpaths and redefining some of the tokens that are already there may be the best course of action. As a bonus, this provides a nice fallback by default: if the page has not overridden these tokens, they simply have their default values.

Syntax

I imagine this would be part of the @font-face rule. However, simply allowing generic font families for the font-family descriptor is not a good solution. Authors typically want to link to their fonts normally, like:

@font-face {
	font-family: Vollkorn;
	src: url("fonts/Vollkorn/Vollkorn-VariableFont_wght.woff2") format("woff2");
	font-weight: 400 900;
	font-display: swap;
}

@font-face {
	font-family: Inter;
	src: url("fonts/Inter-upright-var.woff2") format("woff2");
	font-weight: 100 900; /* stylelint-disable-line font-weight-notation */
	font-style: normal;
	font-display: swap;
}

and then assign them to tokens as a separate step. Perhaps something like:

@font-face ui-serif {
	font-family: Vollkorn;
}

@font-face ui-sans-serif {
	font-family: Vollkorn;
}

or:

@font-face {
	src: resolve(Vollkorn);
	font-family: ui-serif;
}

@font-face {
	src: resolve(Inter);
	font-family: ui-sans-serif;
}

A nice-to-have would be to be able to specify multiple generic font-families, so that e.g. authors can alias sans-serif and ui-sans-serif to the same font-family. Perhaps allowing multiple names on font-family could address this and remove the need for a separate rule entirely:

@font-face {
	font-family: Vollkorn, serif, ui-serif;
	src: url("fonts/Vollkorn/Vollkorn-VariableFont_wght.woff2") format("woff2");
	font-weight: 400 900;
	font-display: swap;
}

[Crissov]

I once proposed to enable authors to redefine color keywords – and was told this was a bad idea. I believe this would be worse because it takes away power from users and hands it to authors.

Although most originate in the Unix/Linux/X11 world, the (non-System) color keywords have universal definitions across browsers, both in theory and practice, whereas generic font family keywords, at least in theory, depend on OS and browser settings or defaults – in practice, it’s not always possible for users to choose different typefaces, or they can just do so indirectly via themes.

Furthermore, is this proposal only about classic generic font keywords or also about those inside generic()?

[LeaVerou]

@Crissov

I once proposed to enable authors to redefine color keywords – and was told this was a bad idea.

It’s not uncommon for proposals to get rejected for years before they get accepted, for a variety of reasons. E.g. inline if() was rejected in 2018 and accepted recently. Or your proposal for redefining system colors vs redefining system colors getting accepted in #9660 😄

Although most originate in the Unix/Linux/X11 world, the (non-System) color keywords have universal definitions across browsers, both in theory and practice, whereas generic font family keywords, at least in theory, depend on OS and browser settings or defaults – in practice, it’s not always possible for users to choose different typefaces, or they can just do so indirectly via themes.

Web pages are already able to define their own fonts, and do so to great extent so that ship has sailed (more than two decades ago lol). This is about included UI components being able to read which fonts the page is using.

Furthermore, is this proposal only about classic generic font keywords or also about those inside generic()?

I think starting from generic font keywords is a good MVP, we can always extend it if the need arises.

[Crissov]

I might have read the proposal too hastily on a tired Sunday morning.

[Crissov]

If this was designed in parallel to custom color schemes in #9660, which would add the ability for author-overridden system color keywords, I guess it should not apply to generic font family keywords used in the font-family and font properties, like sans-serif, but to the system fonts available only in the font property, which include size, style etc. settings:
caption, icon, menu, message-box, small-caption and status-bar.
This list could be extended, although I believe they are virtually unused at the moment.

[LeaVerou]

@Crissov The actual use cases need access to the actual generic font families like sans-serif or monospace.

But yes, the efforts to redefine existing keywords to express page-specific styles would benefit from more coordination.

I was even thinking that keywords like smaller/larger or thin/medium/thick could benefit from the ability to be redefined. There is no reason to have existing keywords that resolve to OS or UA design tokens when they could resolve to page-specific tokens that would be infinitely more useful.

---

Another thing I realized: if this is done via @font-face it makes it harder to alias generic font families to font stacks like e.g. Vollkorn, Garamond, ui-serif. So maybe what is needed is a dedicated construct, in which case it may as well be coordinated with other constructors to override keywords.