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

Mike (Tokens Studio) over 2 years ago

6

🔶 DTCG - W3C Specification Align

Current behavior: After committing a change via Git sync, a “Create pull request” button appears as a one-time prompt. If the user dismisses it (e.g., to review changes first), the button disappears and cannot be retrieved without making another commit. Requested behavior: Make the “Create PR” button permanently accessible in the Git sync UI — not just as a post-commit prompt. This way users can commit, review their changes, and create the PR when ready. Why this matters: Many users follow a review-before-PR workflow: commit tokens, verify diffs or check related changes across branches, and only then open a PR. The current one-shot prompt forces a choice between creating the PR immediately or losing the shortcut entirely. A persistent button removes this friction and supports a more deliberate workflow. Things to consider: Should the button live in the branch/sync panel as a permanent action, or appear contextually when there are unpushed commits? Should it replace the post-commit prompt entirely, or coexist alongside it? How does this interact with different sync providers (GitHub, GitLab, Azure DevOps, Bitbucket)? Not all providers may support PR creation from the plugin equally. Consider showing the button only when there are committed but un-PR’d changes on the current branch, to avoid confusion on branches that already have an open PR. The current prompt appearing on every commit can feel noisy — a persistent button would also reduce this interruption. Source: https://tokens-studio.slack.com/archives/C02JAL48UDN/p1774466570441549

Tokens Studio Team 6 months ago

I have a team of five designers who have the Token Studio professional license. Recently, our Azure Sync has stopped working for our entire team. We are getting an error message that says “There is no branch”. However, the branches DO exist, because we can see them in our Azure DevOps. We have tried troubleshooting: Deleted and recreated the sync settings (multiple times), We tried syncing to different branches (the same error message appears) Removed and reinstalled the Token Studio Plugin Deleted and reinstalled Figma We have checked our Personal Access Tokens in other tools, like Visual Studio Code, and it works fine. I tried contacting the Token Studio team through the online help chat, but I don’t think that it's working as I have submitted multiple requests for help and have received no emails from your team. This issue is affecting our productivity and deliverables; your prompt response to this matter will be greatly appreciated.

lnajera 12 months ago

1

When opening Token Studio in a new Figma file, currently I have no way to access my saved Sync Providers from the initial splash screen. Instead, i have to click on New empty file, then navigate to the Settings tab, then select Apply for the relevant provider, then wait until the dialog prompts for whether I want to pull the tokens or not (this last step feels quite un-required when you’re applying a provider and there are no tokens locally) Instead, I would like to be offered a list of my saved sync providers on the initial splash screen. When I select these, it connects and automatically pulls the set of tokens without further prompting. As a bonus (see end of attached video), i’d like to not have to then go and select the themes i want to use. Not sure how far down the rabbit hole to go in terms of pre-selection,. but for me, the top theme in each theme group is what i need.

Chris Kerr 12 months ago

💡 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.

aln-design about 1 year ago

2

Hello everyone, This one would be very useful for different languages. E.g. for chinese where the lineheight needs to be increased we cannot have the same amount of lines compared to latin. So we need a way to switch between those two languages and automatically adapt the max lines property. I tried the type number but it seems not available. It seems that applying a token as the value for max lines is currently not supported in the plugin. Hint: MaxLines is available in the Figma API, but in order to influence the maxlines, truncate needs to be enabled in Figma as well. → Please add a way to connect the max lines property of a text to a token in Tokens Studio. Thanks, Adrian

AdrianZ-Ergosign over 1 year ago

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.

Nathalie D over 1 year ago

1

❇️ New

+1

Parts of the plugin that could still use some UI improvement Requested Import Variable Features to support: The Styles&Variables button in the plugin is not properly aligned to the pixel grid, causing it to appear larger and slightly blurred. This misalignment is noticeable under the New Set button, which might also be shifted slightly. Proposed solution: Adjust the alignment of the Styles and Variables button to the pixel grid. Consider setting the default size of the left sidebar to ensure proper alignment with the button, enhancing visual consistency and clarity. 😬 The reality 💭 How might we... 💬 Feedback that is valuable How does this issue impact your day-to-day workflow? What workarounds do you have? What other typography features would be helpful to your projects? ↔ Related topics TBD → Jump to post TBD → Jump to post

Keegan (Tokens Studio) over 1 year ago

❇️ New

+2

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?

Sam - Tokens Studio almost 2 years ago

🔶 DTCG - W3C Specification Align

The Composition Token is a Token Type we initially introduced to support design decisions that are typically composed of multiple parts, like typography, shadows and borders. Since then, a lot has changed. The Design Tokens Community Group hosts a token specification on the W3C community group pages for web standards. Although it's in draft form, the tools and technologies working with Design Tokens are trying to align with the W3C DTCG specification. The W3C DTCG specification defines each of these composite design decisions as their own Token Type instead of a generic composition Token Type. → See the W3C DTCG Spec 9.0 Composite types for more details You might have noticed Tokens Studio is aligning to the W3C DTCG spec by introducing as many of the same Token Types as reasonable and feasible. We now support typography, border, and boxShadow as independent Composite Token Types. Migrate away from using the Composition Token Type in the plugin when possible We encourage our community to migrate from using the 'legacy' composition Token Type to a corresponding official token type, as we may deprecate it in the future. An engineer working on Style Dictionary has also formally requested we deprecate this Token Type due to its problematic nature in code. (Github 2800) Could it be a feature in Tokens Studio instead of a Token Type? We know some of you love the idea of Composition Tokens as a way to have a single token which captures the values of as many design decisions as possible applied to a component. In fact, many of you have requested features to push this idea even further. The goal it is to work faster without having to apply so many Tokens manually. While this doesn't align with the direction of the W3C DTCG spec for a Token Type, having a feature that would allow multiple Tokens to be applied in one click could be an interesting feature the Tokens Studio team could work on in the future.

Sam - Tokens Studio almost 2 years ago

2

Token Type

When exporting to Figma from Token Sets, the community would like to see some enhancements to improve their workflow. 1. Add a UI affordance to bulk select all Token Sets in a long list. (Github Issue 3003)

Sam - Tokens Studio almost 2 years ago

1

❖ Variables in Figma

+2

We currently support BitBucket as syncing provider since V2. Below listed enhancements: Add the possibility to sync with on-premise BitBucket installations For other syncing providers we have the possibility to add a Base URL, which can be a good solution for this as well

Tokens Studio Team almost 2 years ago

1

We introduced the new ❖ 🪄 Sync variables and styles is now Export to Figma in V2 of the plugin. Where you can export multiple types in the Wizard to Styles & Variables: When people are now using Variables for their colors, but want to export their Gradient to Styles (which are in the same set/theme), all colors get exported including the Gradients. It would be great if we can add another option, to export ‘Gradients‘ separate from ‘Colors‘ Requested Export Styles: Add extra option, to export ‘Gradients‘ separate from ‘Colors‘

Tokens Studio Team almost 2 years ago

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

Tokens Studio Team almost 2 years ago

3

💚 Quality of Life

+1

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.

Nuthan (Tokens Studio) almost 2 years ago

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.

Дмитрий Альберт almost 2 years ago

2

Token organization

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.

Uday Nair Kapil almost 2 years ago

Currently, users are restricted from scrolling when importing variables due to potential performance issues. However, the limited number of tokens visible at one time can be a blocker. To improve the import experience, it’s good to have the ability to scroll down at least 100 variables

Nuthan (Tokens Studio) about 2 years ago

Hey everyone, it would be great to incorporate support for tokens, variables, and variable-based styles for the "layer blur" effect.

Evgeniy Bogdanov about 2 years ago

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)

Chris Kerr about 2 years ago

2

🐞 Bugs + Blockers

+2