Re: [community-group] Type: font name (#53)

Looking at @kaelig's OP, I think the original issue is still unresolved. While updates to the spec draft have addressed things like [font weight](https://design-tokens.github.io/community-group/format/#font-weight) and [typography styles](https://design-tokens.github.io/community-group/format/#typography), I think the spec needs to still clarify the following for the `fontFamily` type:

1. What do the font names listed as the value(s) of a `fontFamily` actually represent? (and how do they map to actual font files or pre-installed fonts on a user's system?)
2. Should our spec define a set of [generic font families (like CSS has)](https://drafts.csswg.org/css-fonts/#generic-font-families) that can be used? What would that mean for platforms and design tools that don't have that concept?
3. What is the expected behaviour in a tool or platform that does not support CSS-like font stacks, when it encounters a `fontFamily` token with an array value?

FWIW, my suggestions for each are as follows:

### 1) Meaning of `fontFamily` values
Fonts are typically made up of several font faces, which are different combinations of weight (bold, light, regular, etc.) and/or style (italic or normal). In many cases, there are individual font files for each of the faces, though in some cases there may be a single variable font file that covers all of those faces.

[In CSS, a "font family" is a name assigned to a group of related font faces](https://drafts.csswg.org/css-fonts/#font-families). When styling text in CSS, the font family is combined with font style & weight properties and the browser / OS then figures out how to display that (which will often involve mapping the font face back to the corresponding font file and loading that). In CSS, authors can define that mapping themselves via `@font-face` rules. In the absence of a `@font-face` for the specified font family, browsers will instead [look at the fonts installed on the user's system](https://drafts.csswg.org/css-fonts/#localized-name-matching).

Based a _quick_ read of their docs, it looks like Android has a similar concept of font families. Developers can create [font family resources](https://developer.android.com/guide/topics/ui/look-and-feel/fonts-in-xml) in a similar fashion to `@font-face` rules in CSS.

Design tools like Figma & Sketch also seem to have a similar concept (thought they don't explicitly call it font _families_). When styling text, designers typically choose a "font" from a dropdown. However, the listed options are really font _families_ as they will be things like "Times New Roman" and not "Times New Roman Bold, Times New Roman Bold Italic", etc. Once a font has been selected, other controls are used to pick the weight and style.

This gives me some confidence that font _families_ is the right concept to be expressing as a token, rather than font _faces_. 

How tools & platforms actually map a font family + weight + style back to a downloaded / bundled / pre-installed font file does seem to vary quite a bit. However, it looks like it is possible for teams to set things up so that the font family a designer picks from the dropdown in their design tool, matches the font family a developer writes into their code. So, using such names as the value of a token to be shared by all of them seems reasonable to me.

As far as our spec is concerned, I think we just need to do the following:

* Clarify that values of `fontFamily` tokens are names of font _families_ and _not_ names of individual faces within a family
* Add some examples (like mine above) to illustrate how this is represented in different tools and platforms
* Clarify that the definition of the font family (e.g. CSS `@font-face` rules, Android fot family resources, etc. or how a pre-installed system font is picked given a font family name) is out of scope for this spec. (Maybe add a suggestion that teams should aim to set things up across design & dev that the font family names match everywhere though)

### 2) Generic font families
I'm aware of some design systems that intentionally use system font stacks ([for example booking.com](https://booking.design/implementing-system-fonts-on-booking-com-a-lesson-learned-bdc984df627f)), so I think this is a concept folks should be able to express in a design token. I.e. you're saying something like "use whatever the user's default monospace font is" rather than "use Courier New, regardless of what system the user has". Those a very different design decisions.

My suggestion would be to just align with the set of generic font families that CSS has. Perhaps we can add some examples to illustrate how those might be interpreted on non-CSS platforms. E.g. an iOS implementation of a font family design token whose value is a `sans-serif` might simply be to (explicitly) set the font to be "San Francisco".

As far as I know, current design tools do _not_ have this concept. Designers always need to pick an explicit font family. If design tools want to keep it that way, I think there are ways they can work around this when importing/exporting DTCG files though. For example:

* When exporting `fontFamily` tokens that were created inside the design tool, only ever export explicit font family names.
* When importing `fontFamily` tokens from elsewhere that happen to use a generic font family value, map that to one of the available explict fonts wherever the font family value is displayed or altered by the user.
    * However, if subsequently exporting tokens it should preserve the original generic font family value (assuming the user never altered the token value). This way the design decision to use a generic font family does not get lost.
    * Optionally, a design tool may append data to the token`s `$extensions` property to specify what explicit font was displayed in place of the generic one. That might be useful if tokens are later used by designers in other tools or on other OSes. Assuming they support the same extension, they could then display the same font even if they might otherwise map the generic name to something else.

### 3) Font stack behaviour

I believe the behaviour with font stacks should be similar to 2). Platforms and tools that do not have this notion should do the following:

* When reading a `fontFamily` token with an array value, simply take the first item in that array and ignore the rest
* When editing a token, replace the array value with the new, single font family value the user specified
    * Ideally, they may display a warning message to the user to alert them to the fact that they are replacing a font _stack_ with a single font.







-- 
GitHub Notification of comment by c1rrus
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/53#issuecomment-1141014810 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 30 May 2022 11:00:54 UTC