jattasNI
commented
1 month ago Scope of this work as identified during team discussion: (@rajsite @fredvisser please correct if I misunderstood something)
- double check what the existing padding ramp tokens are used for within Nimble
- do one of these (worth a quick chat with the team once we understand the existing use cases to pick between them)
- create spacing ramp tokens to replace the usages that are used for spacing and create semantic tokens to replace the usages that are used for sizing within Nimble
- if that doesn't feel right (too many semantic tokens, hard to distinguish use cases from each other) then consider only creating ramp tokens but naming them "size" instead of "spacing"
- don't yet create semantic tokens for client layout. We have designs for some but we're not sure of our vision yet (layout containers? labels with padding built in?)
🙋 Feature Request
😯 Problem to Solve
1518 discussed the need for a more complete set of spacing tokens, but we deferred that work at the time. This work item proposes a new set of spacing tokens that are directly mapped to pixel values.
🧪 Research
Most design systems use the spacing tokens for both component design and application layout, but some offer standalone layout tokens.
Some also combine the size ramp with context specific tokens.
💁 Proposed Solution
Mimic the Polaris system, except use pixel values.
E.g.
📋 Tasks