💬 Discussion
1Committed and queued
DTCG format update on color tokens and support for color spaces.
Hey everyone, for those who aren't aware, I'm supporting the DTCG as an editor for the spec. I'm collecting feedback on the current state of the proposal for color tokens in the DTCG spec. Early responses are highly appreciated 🚀🚀 This thread holds the context: https://github.com/design-tokens/community-group/issues/137 💬 Feedback that is valuable Proposed format in JSON { "my-token": { "$type": "color", "$value": { "hex": "#xxxxxx", "colorSpace": "color-space", "channels": [0.1, 0.2, 0.3], "alpha": 0.5 } } } Color spaces supported: srgb | srgb-linear | display-p3 | a98-rgb | prophoto-rgb | rec2020 | lab | oklab | xyz | xyz-d50 | xyz-d65 | hsl | hwb | lch | oklch Next steps (from DTCG team) Figure out aliasing. Possibly "hex": "{my-token.hex}", "channels": "{my-token.channels}", but this doesn’t feel very natural or particularly safe. 8 week-long RFC where we ask tool makers in particular for feedback. Below a summary of the thread to get you up to speed if you don't have time to read the whole discussion: Summary of Discussion on Legacy Color Issue (#137) Overview: The discussion revolves around the limitations of using hex color formats in design tokens, advocating for more modern and flexible color representations such as LAB, LCH, and OKLAB. Participants emphasize the need to future-proof the design token specification to accommodate advanced color spaces already supported by some browsers and anticipated to become standard. Key Points: Modern Color Support: Proposal: Standardize on modern color formats (e.g., OKLCH) instead of hex. Justification: Modern color formats offer better perceptual uniformity and more accurate color representation. Flexible Color Representation: Alternative Syntax: "colorSpace": "sRGB", "channels": [0.1, 0.1, 0.1], "alpha": 1.0 Advantages: This format supports various color spaces and offers higher precision compared to hex values. Backwards Compatibility and Toolchain Adoption: Concerns: Current toolchains predominantly support sRGB and hex formats. Suggestion: Include fallbacks to hex while allowing modern formats for future compatibility. Practical Implementation: Fallbacks Example: "colorSpace": "Display-P3", "channels": [1, 0.5,0], "alpha": 1, "fallback": "#FF8800" Tool Compatibility: Tools can adopt modern formats without the immediate need for full support, ensuring smoother transitions. Community Insights and Concerns: Wide Gamut Support: Limiting to hex/sRGB restricts the potential of design systems to leverage advanced color spaces. Precision and Accuracy: Higher precision formats like floating-point numbers
W3C DTCG Spec - Unofficial Token Types
Tokens Studio has several independent Token Types that are not officially recognized in the W3C DTCG Specifications: Spacing Sizing Border Width Border Radius The spec defines a Dimension Token as the preferred type for these properties. If we want to fully align with the spec, Tokens Studio is required to phase out these ‘unofficial’ Token Types. However, we believe the choice should be yours! We have a custom transformation that changes these Token Types to dimension included in the SD-Transforms npm package and we’ve introduced a dimension as its own Token Type. Feedback that is helpful How does having these properties as independent Token Types influence your workflow? What would the impact be if these Token Types would be deprecated, assuming migration was taken care of by Tokens Studio?
🔷 Planned
3Committed and queued
❇️ Per-File Preferences for Active Themes and Export Settings
The plugin currently does not remember user preferences for enabled Themes and export configurations (styles and variables) on a per-file basis. When exporting "Themes," the system defaults to enabling ALL themes, which often doesn't reflect the user's active themes in the editor view for that specific file. This forces users to manually deselect unwanted themes repeatedly for each file, which is time-consuming and increases the risk of exporting incorrect assets, especially when managing multiple files with distinct theme and export requirements. Proposed Solution: Implement a system that saves and automatically applies preferences for each individual file. These preferences should include: • The selection of enabled/active Themes within the editor and for export. • The configuration of which specific styles and variables are marked for export. This way, when a user opens a file, their previously used settings for that file are automatically restored.
Refresh Git Branch Status Without Restarting Tokens Studio
Current Flow when a Git branch is deleted (e.g., after a merge), it still appears in Tokens Studio until the plugin is closed and reopened. This behavior affects the usability of all syncing providers that use branching, including GitHub, GitLab, Azure DevOps (ADO), and Bitbucket. User Feedback It would be helpful to have a “Refresh” button or an automatic refresh feature in Tokens Studio that updates the Git branch status without requiring a restart. This feature would detect changes in branch availability (e.g., deletions or updates) across all supported syncing providers, ensuring the interface accurately reflects the current state of the repository. This enhancement would streamline workflows and reduce the need for repetitive manual actions.
Feature Request: Boolean Token Type Toggle
Request: Add a clickable toggle for true/false in the Boolean token type, allowing users to quickly select the value instead of typing it manually. Why it's useful: Speeds up workflow. Reduces manual input errors. Improves usability for managing Boolean tokens.
🟣 In Progress
Actively being built
No 🟣 In Progress issues
👀 Beta Testing
Actively being built
No 👀 Beta Testing issues
☑️ Completed
7Recently shipped
💬 Add support for scoping and publishing variables and styles
Our power users who rely on the plugin to manage very complex systems would like to control scoping and publishing decisions using Tokens Studio. Today our community can use Figma native features in Variables to control which parts of their design system are visible: locally scoping variables to only appear in certain areas of the Figma UI non-locally scoping variables to only appear in certain areas of the Figma UI publishing collections of variables or styles as libraries that can be consumed in other files.
🎨 Expand gradient color support
Today you can use a color token and some very specific value formatting to create a simple linear gradient. However, we know designers use more styles of gradients that are currently available in Figma natively. radial angular/conic multi-stop with position defined 😬 The reality The Design Tokens Community Group has listed a gradient as a specific token type we could introduce. Today there is a known issue with gradients where stops less than 0% or greater than 100%, are not working properly, and its challenging to define the stops in the plugin. Like many token types, if there are extra spaces in the values, the gradient will not work as expected. 💭 How might we... Expand gradient color offering to designers using the plugin in a minimum lovable product approach? 💬 Feedback that is valuable How does this issue impact your day-to-day workflow? What workarounds do you have?
🔁 ❇️ Import Variable Enhancements
With some part of our community uses import variables, they have expressed some enhancements to improve their workflow: Requested Import Variable Features to support: Import Variables should include Themes [Pro] Currently when importing variables, collections and modes are translated to sets and subsets and don’t include the plugin’s Themes. We might want to support this as exporting variables translates theme-groups and themes (for pro users) to Figma’s variable collections and modes. Selective Import of Variable Modes When importing variables into the plugin, it’s good to have the ability to select which variable modes will be imported. This would provide greater control and flexibility during the import process, allowing users to tailor the import to their specific needs. Importing Typography Variables Loader / Indicator for Importing Variables Import Variables in Order Created Also Import (update) Deleted Modes or Collections
Persisting (auto-applied) themes
💡 Current When selecting and applying a theme using Tokens Studio, all components instances in the Figma file get the selected theme applied to them. Pulling a new instance of a component, or switching to a different component variant (when not sharing an internal base component), result it having these components not having the desired theme, and forcing users to re-apply the theme, making a pretty disruptive experience to design. ———— ✅ Desired Enable the desired/selected theme to be automatically applied when: A new component instance is pulled into the file A component already in the file and themed changes configuration (ex switching to a different variant, size, and whatnot) ———— 🚀 Benefits Enable individuals or smaller teams not on Figma Enterprise (4 modes limit) to still have a convenient way for their users to switch themes and have a less disruptive workflow.
Exporting to Figma causes all Figma variables to be republished
If I change one thing in Token Studios (bye it add a new token, delete a token, edit a token name or value) and then export Variables & styles to Figma, when I publish the Figma library, Figma thinks that every variable and style (and therefore everyone connected component) has been modified and republishes everything This creates issues when you want to adjust one component’s token and publish just that token, whilst also having other tokens and components in the file that are not ready. It also has the issue of making the Figma publication very slow (for a decent sized library) The screenshots attached were the result of updating one existing token value and exporting to Figma (the library prior to this had been full published and had no outstanding items to publish)
🔎 Search enhancements
Today we have search abilities in several places in the plugin but the community has requested a few enhancements Fuzzy search When the token name is "A.B.C.D", when the user enters the keyword "A.C.B", the design of the token "a.b.c.d" can also be searched. Expanded areas of search indexing From the main plugin page I may want to search by a keyword in the token description or other metadata in addition to the token name. Highlight where search terms exist outside the current selected JSON Files. Today you have to manually click through every Token Set to see if the searched term exists. 💬 Feedback that is valuable How does this issue impact your day-to-day workflow? What workarounds do you have? ↔ Related topics TBD → Jump to post
Plugin Tokens Tab - UI Affordance to collapse/expand groups
On the Tokens Page of the plugin - ideally there would be a single click operation to expand or collapse all branches created by Token Groups. It’s very inconvenient when working with large trees - It’s a lot of manual effort to close all parent groups until the one that is needed is reached. A keyboard shortcut could work (for example [CMD], [SHIFT] + click on a node) and automatically collapse all others.