Add support for updated tokens conventions (dimension) #6
Conversation
- Removes assumptions around "light" as a default mode, since current theming algorithm does not have explicit dark or light modes. Instead uses "default" as default mode - Updates to remove handling of aliases to primitive values, as primitive values are no longer included in Figma JSON output - Adds handling for imported dimension values (padding, gap) as numeric values - Creates separate collections based on top-level grouping (i.e. "Color" and "Dimension"). This is because each grouping may have their own grouping-specific modes. For example, density should only affect dimension values.
|
See accompanying changes to token output to format dimension tokens similar to color groupings: WordPress/gutenberg#73407 |
|
Amazing :D Tiny detail; should the modes be capitalised? 🤔 |
They could be. The challenge here is that these modes are driven from DTCG extensions, so often use a lower-cased, kebab-case or dot-delimited format in how they're named. We could capitalize them through some utility function (an equivalent of a Lodash capitalize, for example), but it may not always be perfect. One example being something like how we're using |
|
There's also a point to both maintainability and future compatibility. What @ciampo implemented around formatting color names to values like With Figma mentioning that they plan to launch both DTCG imports as well as improved management for variable collections, I'm not sure how compatible or necessary all of our manual finesse-ing of token names will be. |
Maybe we could manually map these. I don't think there'll be too many modes (I hope not, for the sake of folks working on the designs), so if it comes down to mapping "Compact", "Comfortable", and "High DPI", that seems manageable enough. |
|
Hah, like I said, it's a tiny detail. If there's not a very simple solution we don't need to worry about it imo. |
|
Nevermind, Node version issue. Working now :) |
|
I notice none of the primitive tokens are imported. Is that intentional, or perhaps a consequence of how we expose them in the Gutenberg theme package? From my testing:
One other detail I'm not sure about, and I guess it's something we can discuss separately, is how we organise the variable Collections in Figma. Based on our need for modes ChatGPT suggests the following:
Either way it would be nice to remove the |
This was a side-effect of the inlining changes in WordPress/gutenberg#72890 , which was both surprising and not surprising to me. I think it's a good point to raise, since I could see some value in representing the raw set of values in the Figma collection. On the other hand, I think the reasons for inlining values in CSS (i.e. public consumers should only need to care about and reference semantic values) could also extend to Figma variables. On the third hand (😂 ), the future Figma DTCG import support will likely import these primitives anyways, so there could be some value in aligning (or not bothering if we can plan for that future support). |
Yeah I was looking at this earlier as well and thinking it quite verbose (plus the lack of formatting around the slash). Depending if we need to bother including both semantic and primitive, my thought was that we could call these collections "WPDS [Grouping]" (i.e. "WPDS Color" and "WPDS Dimension" currently). |
|
Yeah I kind of came to the conclusion that it's not essential for the primitives to be included in Figma. As you say, designers should always be using semantic tokens, and I guess it matches the code after recent updates. This changes how we approach the collection organisation too. We could even potentially have a single 'WPDS' collection with Colors and Dimensions as groups, which would simplify things, but also restricts modes which may cause issues later. On balance I think your suggestion "WPDS Color", "WPDS Dimensions" sounds good. |
|
Yeah I'm not huge on the separate collections, but it's necessary if we ever need to support more than one mode being active at a time. |
While we don't export primitive values, alias handling should be a basic functionality to support that we might leverage in the future
Being removed from output
|
Latest commits remove "Tokens/" from the collection name (e.g. "WPDS Tokens/Dimension" ➡️ "WPDS Dimension"). This needs to be tested with the output from WordPress/gutenberg#73407 , since it now also encodes expectation that the output will no longer include "Semantic" groupings. I think I'm reluctant to avoid introducing nice labels for modes, for improved future compatibility with generic DTCG tokens imports if we can ever get to a state where we don't need to maintain this ourselves. |
|
I think there's a bug with scope application:
Edit: I notice I'm still seeing the "Semantic" groupings too, so I'm thinking I have an issue with my build somewhere 😪 |
|
@jameskoster You'll need to use the The original instructions pointed to the copy from |
|
I thought that was what I was doing, but maybe the json wasn't building correctly. It's working now :D 
|
We no longer import primitive tokens
|
One small scoping issue I noticed; foreground colors are scoped so they can be applied to strokes. I think we may have originally set it up this way because we were exploring stroke-based icons. But that has been de-prioritised, so we might want to scope stroke colors only to strokes for now. Otherwise this seems good :) 
|
|
Update: With Figma now supporting DTCG token imports natively, I'm going to propose we invest our efforts into ensuring our tokens can be imported directly. In other words, I'd like to suggest that this plugin has served its purpose but is no longer necessary and should be sunset. In Gutenberg, I've proposed and will be merging a handful of pull requests to improve support for importing tokens into Figma: |
Testing Instructions:
manifest.jsonfrom the checked out copy of this repositoryfigma.jsonfrom Gutenberg output on theupdate/theme-figma-plugin-densitybranch (source)dimension.mov