Is there a way to still include boolean and string type functionality?

[torstendaeges]

Hallo everyone. I'm fairly new here and it goes without saying that I haven't read everything, so please bear with me.

Noticing the change not to allow basic JSON types in the spec anymore, I read up on the topic.

There were mentions that some types might not have obvious applications in UI design. Working on a design system currently, I just wanted to check in with a few thoughts - and I hope that opening an issue for that is ok. I'm not arguing to reopen that "JSON types"-discussion, I'm just wondering if there could be possibilities, like DTCG-specific types, for those appllications in the future.

Boolean:
I do think there are applications in UI design for a boolean type. E.g. the visibility of an element when defining the appearance of responsive components. Seeing what Figma is doing with modes, this becomes especially apparent.

String:
Same goes for string. It could be used to centrally define certain default captions or labels, placeholder texts, identifiers for modes, prefixes or other strings.

Number:
I know it's already been included for several good reasons, and here's one more: We use it to define the number of columns in our grid definitions.

I guess I'm wondering if boolean and string could still be included, maybe as a spec-specific type. I think these two are too important and basic to relegate them to proprietary extensions, especially since Figma now uses them too.

Also, P.S.: Since text-alignment was brought up, I was wondering about text-decoration and text-decoration-thickness.

Thank you all for the great work you're doing here - so many familiar names too. :)

[drwpow]

I can see several benefits of adding string and boolean types to the spec, and I’d also like to see this added!

This is related to #134 and “create-your-own-type” which historically has been what the spec was trying to move away from by its design. In a pre-spec world, token types would be up to individual teams to define and enforce, which means there’s no concept of “validation,” and design engineers have to reinvent the wheel at every company they work at since generic tooling is hard to build (or it has to be incredibly configuration-heavy). So in one sense, I think it’s natural for DTCG to discourage this design initially.

That said, users of the working draft of the DTCG spec are used to the builtin types, and have had to implement workarounds for their own token types like this. After all, tokens.json is a great source of truth to store custom, one-off tokens meant for specific design systems, because that DS is already storing the rest of their standard tokens in there, too.

Proposal

So would it be accurate to frame your proposal like so? I can see this basically just reserving these type names, and nothing else:

{
  "myBoolean": {
    "$type": "boolean",
    "$value": true
  },
  "myString": {
    "$type": "string",
    "$value": "foobar"
  }
}

Pros / cons

In weighing it out, this isn’t exhaustive, but some likely arguments for- and against I can foresee:

• ✅ Parity with Figma. Figma already supports strings/booleans in Figma Variables. The cat’s out of the bag; why not support parity?
• ✅ Prevent future collisions. The alternative to not having dedicated $type: "string" / $type: "boolean" types is just making users specify their own custom $types. Which could cause conflicts in the future, if they are using a name that eventually becomes an official type
• ✅ These are unused anyway. There will likely never be a $type: "string" or $type: "boolean" defined anyway whose usecases diverge from this proposal; why not standardize it?
• ❌ It overlaps with existing types. What’s to stop users from storing a dimension as $type: "string"?
• ❌ It prevents generic tooling from being created. Tools couldn’t know how a generic $type: "string" translates to a native app vs web, because there’s no information to do so.

The last two I don’t see as real issues, because tooling not being able to translate these well would discourage using these types in the first place unless it was for custom, one-off reasons. By using a more semantic type such as dimension or duration, tooling can do all the work translating to different platforms for you. But if a user has decidedly used $type: "string" instead of those, they are very likely outlining a non-standard concept for their own usecases. Same for $type: "boolean". But, the nonstandard usecase still qualifies as a “token” in their unique design system

So by marking these as “catchall” types, it just seems like a win–win for the spec: it dramatically lessens ad-hoc extensions to the spec where people are declaring $type: "myCustomType" willy-nilly. And it allows escape hatches for users to declare their own logic. I think they come with the explicit understanding that these are both “up to the user to implement,” and as long as that contract is clear on both ends, I think it would be a good addition personally.