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

6

πŸ’‘ Plugin Feedback

❇️ 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) 1 day ago

πŸ’‘ Plugin Feedback

πŸ’¬ 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 2 months ago

πŸ’‘ Plugin Feedback

πŸ’‘ 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 2 months ago

1

πŸ’‘ Plugin Feedback

πŸ’‘ Requests

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

Tokens Studio Team 2 months ago

3

πŸ’‘ Plugin Feedback

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

πŸ’‘ Plugin Feedback

πŸ”· Planned

[Penpot] Sync with GitHub

We are implementing the ability to store design tokens on remote storage and sync them with a GitHub repository. This feature will enable users to connect to a GitHub repo, manage their design tokens, and sync changes effectively. The following functionalities are essential for the successful implementation of this feature: Connecting to a GitHub Repository: Users can connect to a GitHub repository that contains design tokens by providing the required credentials: Personal Access Token, repo name, branch name, file path, and an optional base URL. Users can connect either to a single JSON file or to a folder containing multiple JSON files, including nested folders. Upon successful connection, the system should sync the tokens from the repository. Pushing and Pulling Changes: Users can push changes made to the design tokens in the Penpot to the connected GitHub repository, creating a commit. When pushing changes, users are prompted to write a commit message. The commit message cannot be blank; it must contain text. Users can pull changes from the GitHub repository to sync the latest token updates. Before finalizing a push or pull action, a diff should be displayed to show the changes being made. Error Handling: Proper error messages should be displayed if any issues occur during the connection, pushing, or pulling processes. This includes scenarios like incorrect credentials, network issues, or missing files. Additional Features (Good to Have): Users should be able to create a new branch directly from the Penpot interface. The system should support storing more than one repository and allow users to switch between them. Users should have the ability to see the list of branches on the connected repo and switch between them. Behavioral Considerations: If the user connects to a repo without any files, the system should display an error message indicating that there is no branch, so the process cannot proceed. If the specified file is missing, and there are no tokens locally, the system should still push the metadata. If there are existing tokens locally, it should reflect all base tokens and token files from the repository in Penpot If the application is closed without pushing changes to GitHub, the changes should be saved locally. When the app is reopened, it should recover and display the local changes.

Esther Cheran 6 months ago

πŸ–‹οΈ Design Tokens in Penpot

🟣 In Progress

[Penpot] Token sets

Token sets allow users to create groups or collections of tokens, providing an organized and manageable structure for design tokens. Token sets have several key features and behaviors: Default Token Set: On a new file, there will be a token set already existing. Creating New Sets: Every time a new set is created, it will be ordered after the existing sets. The name of the token set is not included in the name of the token. Users can create a token set and give it a unique name. Token Naming and Organization: Tokens with the same name can be created in different sets. Token sets should be ordered for clarity and organization. Reordering Token Sets: Users have the ability to drag and reorder token sets. The order of token sets is important for resolving token values. Tokens with the same name in a latter token set override the value of the token in an earlier token set. Enabling/Disabling Token Sets: Token sets can be enabled or disabled. If a token set is disabled, it will not be used in resolving the value of a token. These features ensure that users can effectively manage and prioritize their design tokens, facilitating a streamlined and flexible design workflow.

Esther Cheran 6 months ago

πŸ–‹οΈ Design Tokens in Penpot

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

πŸ’‘ Plugin Feedback