Have a request? Something unexpected happening?

We'd love to know what you are thinking, seeing or expecting.

Pinned

πŸ’¬ Discussion

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 prevent rounding errors common in hex conversions. Consensus and Next Steps: Flexibility in Spec: Propose allowing both hex and advanced color formats to coexist in the specification. Future-Proofing: Emphasize the importance of a forward-compatible spec that adapts to evolving design tools and browser capabilities. Conclusion: The discussion highlights the need to move beyond legacy color formats and adopt a more flexible, future-proof approach in the design token specification, balancing current toolchain limitations with the advantages of modern color spaces. ↔ Related topics 🎨 Expand support for color spaces β†’ Jump to post

Mike (Tokens Studio) Over 1 year ago

6

Azure Sync Provider Not Working

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 4 months ago

1

Backlog

Improve Token Studio initialisation for new Figma files

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 4 months ago

β˜‘οΈ Completed

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.

aln-design 5 months ago

2

Connect the max lines property of a text to a token in Tokens Studio

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 9 months ago

πŸ”· Planned

❇️ 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.

Nathalie D 10 months ago

1

Archived

❇️ Plugin UI Enhancements

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) 12 months ago

πŸ’¬ Discussion

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?

Sam - Tokens Studio About 1 year ago

πŸ’‘ Requests

Deprecate Composition Token Type

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 About 1 year ago

2

β˜‘οΈ Completed

πŸ” ❇️ 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

Tokens Studio Team About 1 year ago

3

πŸ”· Planned

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.

Nuthan (Tokens Studio) About 1 year ago

β˜‘οΈ Completed

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)

Chris Kerr Over 1 year ago

2