Re: [community-group] Remove REM/EM from specification? (#218)

This discussion on the use of design tokens, their units, and the surrounding tooling has been incredibly insightful. Here are my thoughts:

### Main Points of the Discussion:
1. **Design Token Units**: Central to this debate is whether design tokens should come with units like `rem` and `px`, or if they should lack such units, leaving the responsibility of conversion to the tooling.
2. **Source of Truth**: It's crucial to pinpoint the definitive "source of truth" for design tokens. Is it design-centric tools like Figma, or should it be a dedicated repository or system?
3. **Tooling**: The range of tools involved in the workflow of creating, maintaining, and exporting design tokens is vast. They include Figma Plugins, Token Studio, Theo/Style Dictionary, and many others. Each tool has its strengths and quirks, and the choice often depends on the specific use case and workflow of the design and development teams.

### My Proposed System:
I've suggested setting the root font size to `10px`. This simplifies the correlation between the `rem` and `px` units, mainly targeting developer convenience and making conversions more intuitive.

**On that note**:

This approach offers a pragmatic solution for web development. The ease of converting `rem` values into pixel values by shifting a decimal point is attractive. However, considerations remain:

1. **Flexibility**: While perfect for the web, this system might have challenges on platforms like iOS and Android, which standardize on `pt` and `dp` units. The crux of the matter is whether design tokens should be versatile across platforms or if tool-specific conversions should bear that weight. Or, is there a universal standard, like the one I'm suggesting?

2. **Accessibility**: The draw towards `rem` stems from its adaptability to user preferences, such as their default font size. Assigning a fixed pixel value as the root might impede this accessibility feature. Nonetheless, this can be balanced if other accessibility aspects are championed by developers.

3. **Adoption**: The rationale behind this system is straightforward. However, widespread adoption might face challenges. Many developers and designers are accustomed to the default 16px root size. Changing this established norm could be challenging.

Recently, Figma has introduced local Variables, their own take on design tokens. This addition can be seen as a game changer, as it brings the management of design tokens directly into one of the most popular design tools. It simplifies the workflow, reducing the need for external tools or plugins for creating and managing design tokens.

However, one must consider whether this creates a new silo, potentially leading to inconsistencies if other tools or platforms are involved in the workflow. With that in mind, it is crucial to establish a clear "source of truth" and consider how this new feature integrates with the existing design and development processes.

In conclusion, my system presents an optimized route for web applications. The broader challenge is finding a middle ground. Should design tokens be platform-specific or universally neutral? While my proposal is tailored for web contexts, the dilemma remains: should we adopt a universally accepted standard for all platforms or place conversion responsibilities squarely on the tools?


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


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

Received on Thursday, 3 August 2023 17:58:44 UTC