Replies: 1 comment 3 replies
-
|
How does this affect the authoring experience for design? I know it's a bit complicated and there are thoughts about that workflow in place. On iOS we've been thinking about that too and I'm curious if these object-based values have an analog in Figma. Can design easily make changes to this or is there a step that has to happen between them and tokens? |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Overview and history
Related to the previous RFC for Composite tokens for Drop Shadow and Typography, I've published a snapshot release of what a composite token could look like for a drop shadow. The primary purpose of this would be to enable implementation teams to test it out and give feedback.
Proposal
Here are the release notes for the @adobe/spectrum-tokens@0.0.0-s2-composite-drop-shadow-20250319174850 snapshot package:
Token Diff
Tokens Changed (3)
main|snapshot-s2-composite-drop-shadowAdded (3)
drop-shadow-emphasized-default-ambientdrop-shadow-emphasized-default-transitiondrop-shadow-emphasized-default-transition-keyExample composite token JSON
Additional context
This composite token type would be possible with the current design token authoring workflow because Tokens Studio has a composite token type for box shadows.
A similar solution could be used to combine typography styles into a composite token in the future.
Alternatives
Instead of a new composite token type, we could also generate a new token for each value inside of the value object.
Although it has more lines of code, it contains the same amount of data, with some data context moved to the token name string.
This discussion was created from the release Composite token proof of concept (s2 drop shadow).
Beta Was this translation helpful? Give feedback.
All reactions