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

If you think of design tokens as expressions of design _intent_, then there is a big difference between the choice of a relative unit like `rem` and a ln absolute one like `px`. The former is saying "I intend this size to be relative to the user's choice of default font size", the latter is saying "I want this size to be the same, regardless of the user's settings".

I believe it's important to be able to express both of those intents, which is why the DTCG spec allows both.

We've borrowed CSS's unit names as we felt those are likely to be familiar to many folks working in and around design systems. I suppose we could have adopted Android's `sp` for this purpose instead, but I suspect less people are familiar with that. Or we could have invented our own, but then we'd probably have ended up writing stuff like "the DTCG `flibble` unit is a multiple of the user's preferred font size - _just like `rem` in CSS_" 😜

As for why have units at all,  think of the `px` and `rem` units in the DTCG spec as a means of expressing the relative vs absolute dimension intent I outlined above.

In order for translation tools like StyleDictionary or Cobalt to "know" how to convert a token value into the appropriate platform-specific value and syntax, they need that info. As others have pointed out, it's not just the Web that has this concept. For example, Android has `sp` which is essentially 1/16th of a `rem`.

Sadly design tools like Figma do not currently have this concept, but I don't believe that's a reason to limit the spec's expressiveness (if anything, I'd hope it might nudge design tool makers to adding support for something akin to `rem`). I'm actually more concerned about whether or not we ought to add more relative units (E.g. `%`, `vw`, `vh`, `ch`...) in the future, so as not to limit what design intents people can express in the format.

It's also worth noting that design tools (or _any_ tools that might create or manipulate DTCG files) don't necessarily need to expose the "raw" DTCG values to their users. Just as an export tool like StyleDictionary might read a DTCG `rem`  value and convert it to, say, an equivalent `sp` value. A tool like Figma could read a DTCG `rem` value and display it to users in some other way. It's also reasonable (though not ideal) for a lossy `rem` to `px` conversion to occur in tools or platforms that lack the concept of sizes that are relative to the default font size.

> In the future, I'd imagine nobody would manually type W3C Design Token JSON files but depend on Figma Plugins to create the files for them. Because Figma edit seats are somewhat expensive, developers typically do not have edit access to Figma libraries, so they are unable to run plugins. Therefore designers will be outputting JSON for the developers

While I'm sure many teams will operate in that way, we can't assume that designers are always the exclusive "owners"  of design tokens, or that there is just a one-way flow of information from design tool to code. Tools like ZeroHeight, Supernova, Interplay and others already let you create and edit tokens, which can then be synched back to Figma as well as exported to code. Other tools to visualise, organise and manipulate tokens are emerging too, such as Token Studio's Flow tool. My hope is that the DTCG format will one day allow teams to pick and mix any combination of such tools and constrict whatever design token flows they want.

The "source of truth" for a team's design tokens thereofre doesn't have to be Figma. It could be a DTCG file in a git repo (which might be edited by hand or via some dedicated token editor tool), or some kind of token management tool that can import & export DTCG files. In that case, _that_ is where are team can capture their absolute vs relative design intents - as long as we retain the `rem` unit 😜. A design tool like Figma could then read from that and, until it has some native equivalent to `rem`, do a lossy conversion to px (yes, I know Figma doesn't display a unit, but let's face it those numbers are effectively absolute px (web) /dp (Android) / pt (iOS) values).

When implementing designs, a developer would hopefully use the token names used in the design as their guide and referemce the respective variables in their code which would be relative or absolute as needed.

Long story short, I'm very much in favour of keeping the `rem` unit (and units in general) in the DTCG format. Unless there are steong objections, I think we should close this issue.

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


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

Received on Thursday, 1 June 2023 08:22:40 UTC