design-system icon indicating copy to clipboard operation
design-system copied to clipboard

How to deal with inheritance?

Open gfellerph opened this issue 1 year ago • 0 comments

In CSS (Cascading Style Sheets), inheritance is one of the core concepts that reduces the amount of code needed to style a website considerably. The current approach to defining typography tokens does not make use of inheritance because Figma does not offer this concept (in a way font styles resemble the concept, but font styles are not inheritable).

How can we profit from the efficiency of inheritance of CSS while not optimising the token system for the web (design tokens should be generic design decisions and not targeted at a specific platform).

Issue with the current implementation

The current implementation defines a composite font token for every component. This token contains values for font-family, font-weight, line-height, font-size and letter-spacing:

{
  "legend-l": {
    "value": {
      "fontFamily": "{post.sem.font-family.default}",
      "fontWeight": "{post.core.font-weight.700}",
      "fontSize": "{post.core.font-size.32}",
      "lineHeight": "{post.core.line-height.120}",
      "letterSpacing": "{post.core.letter-spacing.default}"
    },
    "type": "typography"
  }
}

Those values are all inheritable. When set at document root level, they only have to be set where they derive from the default. Defining all those values over and over again, creates a lot of unnecessary repetition.

Proposed solution

Since inheritance is a web related feature, it should only be taken into account for the file exports targeted at the web platform in the tokens package (the .scss files). With the custom transformer written to generate these files, it could be possible to de-dupe font definitions that don't deviate from the standard.

The challenge with this approach will be to track down all references through the semantic layer to figure out if the component needs a definition for letter-spacing because there might be a change based on one of the semantic layer definitions.

Alternative solution (manual)

Another solution could be to manually analyse each component and define the properties that could change and therefore need to be set in the components style definition (font-weight for titles as an example because that deviates from the standard font weight).

The challenge with this approach would be maintainability over time and the big possibility that token changes get introduced later that don't get propagated to the dev team which would lead to incorrect styling.

Have any other ideas?

gfellerph avatar Jul 31 '24 08:07 gfellerph