Typography type feedback

[c1rrus]

Is the typography composite type fit for purpose? Should the lineHeight sub-value use a number value, dimension or a new line-height type?

Please share your feedback, thoughts and ideas in this issue.

[mkeftz]

Thanks @c1rrus for the amazing work on composite types. It's been fantastic from a tool makers perspective to have these properly defined.

There are a couple of things on Typography I'm unsure of:
-- I feel it's missing a few frequently used properties. Specifically fontStyle, textDecoration, and textTransform. This makes it hard to translate between different design tools Text styles and design tokens.
-- With the fontName property, is there a reason this is not fontFamily? This might be more of a personal preference, but all the other names align with their css equivalent.

[ilikescience]

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.

CSS properties that modify text

• 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

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.

[TravisSpomer]

Really insightful. Typography is interesting because it does feel like some of those properties (like the specific five you called out) are very "core" to the look and feel and function of text, and some of them like white-space and text-align and text-decoration are instead things that you think of again each time you want to use that text style. In web terms, the former group are the sorts of things you'd set as CSS/SCSS variables or on high-level elements like html or body, and the latter are the sorts of things you'd use for much more scoped situations like div.mySpecificUsage.

I think the crucial questions are: do we think we can adequately nail down the right set of those "core" properties in the first group? Do all people have approximately the same mental picture of what text properties are really core and which ones are things that you decide for each specific instance of text? If we can't answer "yes" very confidently to those two questions, I'm a lot more inclined to agree with you here.

[drwpow]

Re the “open spec” idea from @ilikescience, I don’t think including all the properties would be too hard on implementers, because most tools will be somewhat platform-specific. For example, several of the 57 CSS properties named don’t work for all browsers on the web yet. Or if they work on web, they may not for native apps. Since typographic attributes are somewhat platform-specific, there could be a wide list of properties and every tool only selects the subset its build target can use.

[christophlocher]

I, too want to point out that the current selection of properties seems very restrictive.

To make it more explicit these are a few I use regularly in our token system:

• text-underline-offset and text-decoration-thickness
• word-spacing
• text-transform

If they were missing from the spec I would definitely be unable to use the token format for our design tokens. I do think they are important because they finally allow designers more control over the typography in digital designs.

My preferred solution would be to have an open spec (minimum requirements + users can add any property), with a list of spellings and definitions for common properties, that is not exhaustive but serves as a guide to tool-makers.

If the decision is made to make the spec closed and the list exhaustive, there are some properties that I’d consider out of scope because for me they are about the box that contains the type, rather than the type itself if that makes sense? E.g.:

• hanging-punctuation
• hyphens
• text-align

---

On another note, I think the description of the lineHeight property is somewhat ambiguous:

• lineHeight: The vertical spacing between lines of typography. The value of this property must be a valid JSON string or a reference to a string token.

“The vertical spacing between lines of typography” doesn’t seem quite right to me. It sounds like it is describing leading, as in the size of the lead strip put between two lines of text, when it is (probalby?) actually refering to the space from one baseline to the next (as in CSS and common design tools).

[solemone]

Hi Community,

how about open font features. E. g. to activate a stylistic set? I would like to use a token like fontFeatures. Maybe with an array of active features. Like:

fontFeatures: ["ss07", "liga 0" ]

or a little bit more explicit:

fontFeatures: [ { "ss07": "on" }, { "liga": "off" } ]

[emilianorodriguez]

Hi,
I wonder if you have considered adding color as part of the composite typography token.

Whilst I know color is not part of the typography properties as fontSize, lineHeight or even textDecoration, it is intrinsically related to the overall style. ie: assigning specific colors to links or connoting danger through the use of red typography is a common practice.

The use of a "typography composite token" relating 2 existing tokens could be extremely beneficial to the overall simplicity. What I mean by this is the following use case.

1. Create tokens specific to font family, size, weight, etc.
2. Create, for example, a Heading 3 token, referencing the previously created font family, size, weight...
3. Create a "Danger heading 3" token, referencing the Heading 3 token + a color token ( ie: color.danger)

This logic could be applied to even a default color across typography, communicate different status, etc...

[DeDiamondPro]

I think that the type for lineHeight and letterSpacing are not fit for purpose,
In both of these variables the following values are useful:

• px
• em
• rem

Currently lineHeight only supports em and letterSpacing only supports px and rem.

I would like to suggest the creation of a new type with a name like fontDimension which supports px, em and rem and gets used by lineHeight and letterSpacing

[ch99q]

Why do the Typography values use "fontFamily" instead of "family"?

When comparing, e.g. shadow to typography I see that shadow's values are more context-based, but when writing typography, it's more based on the CSS properties.

"microcopy": {
  "$type": "typography",
  "$value": {
    "fontFamily": "{font.serif}",
    "fontSize": "{font.size.smallest}",
    "fontWeight": "{font.weight.normal}",
    "letterSpacing": "0px",
    "lineHeight": "1"
}

We could make it more context based so it matches the other types in the spec by replacing some of the keys like this?

"microcopy": {
  "$type": "typography",
  "$value": {
    "family": "{font.serif}",
    "size": "{font.size.smallest}",
    "weight": "{font.weight.normal}",
    "spacing": "0px",
    "height": "1"
}

The only problem I encounter is the height property's meaning since we removed the "letter" part.

[lukasoppermann]

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 encounter an issue were we don't define a lineHeight so that it inherits the parents lineHeight in css. However this is not possible with the current definition as lineHeight is required.

I think there should be a minimum requirement like fontFamily and fontSize and leave the rest optional.

CC: @ilikescience