Re: [community-group] Typography type feedback (#102)

I think that the typography composite type serves as a good test balloon (or stress test, or canary in the coal mine, maybe) for some of the higher-level ideas about composite types.

For example, #86 defines a typography token as one that must include the following five values:
- fontName
- fontSize
- fontWeight
- letterSpacing
- lineHeight

However, in CSS alone, there are at least 57 properties that can change the way text is displayed.

<details><summary>CSS properties that modify text</summary>

- direction
- font
- font-family
- font-feature-settings
- font-kerning
- font-language-override
- font-optical-sizing
- font-palette
- font-size
- font-size-adjust
- font-stretch
- font-style
- font-synthesis
- font-synthesis-small-caps
- font-synthesis-style
- font-synthesis-weight
- font-variant
- font-variant-alternates
- font-variant-caps
- font-variant-east-asian
- font-variant-emoji
- font-variant-ligatures
- font-variant-numeric
- font-variant-position
- font-variation-settings
- font-weight
- glyph-orientation-vertical
- hanging-punctuation
- hyphens
- letter-spacing
- line-break
- overflow-wrap
- tab-size
- text-align
- text-align-all
- text-align-last
- text-combine-upright
- text-decoration
- text-decoration-color
- text-decoration-line
- text-decoration-style
- text-emphasis
- text-emphasis-color
- text-emphasis-position
- text-emphasis-style
- text-indent
- text-justify
- text-orientation
- text-shadow
- text-transform
- text-underline-position
- unicode-bidi
- white-space
- word-break
- word-spacing
- word-wrap
- writing-mode

</details>

I know it's a bit obtuse to imply that anyone would use _all_ those properties in any given type definition. But It raises an important point: when we choose a subset of these options, we're going to leave out use cases.

One approach to this problem is to allow composite types to "openly defined," in that they have a _minimum_ requirement for definition, but that an author may choose to include as many additional properties as they see fit.

I'd suggest that if the spec is "open", each composite type is defined as the minimum amount of information necessary to render a given element. In the case of typography, that might just be "fontName" (or "fontFamily") and ("fontSize").

This approach takes a lot of pressure off of the spec, but makes it harder for implementers on the tool side.

Another approach is to use a "closed" definition — each composite type has a _maximum_ set of properties, and authors can choose a subset of those properties.

In that case, the typography composite type would be defined as one that includes any number of a fixed set of properties (like the ones in the collapsible above).

This approach makes it much easier for implementers, since the possibilities for the token are limited. But it does put a lot of pressure on the spec to get the list "right."

---

Typography is definitely the pressure test here; for a token like "shadow," it's possible to just require the full list of properties, since that list is short. But the approach should be consistent between composite types, so typography is a good place to start with some of these challenging questions.

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


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

Received on Tuesday, 25 January 2022 19:41:18 UTC