feat(tailwind): switch spacing utils to use space token CSS props#13770
feat(tailwind): switch spacing utils to use space token CSS props#13770
Conversation
| 13: "3.25rem", | ||
| 2.5: "var(--calcite-space-sm-plus)", // Deprecated in v5.0.0, removal target v6.0.0 - use `--calcite-space-sm-plus` instead. | ||
| 4.5: "1.125rem", // Deprecated in v5.0.0, removal target v6.0.0. | ||
| 11: "2.75rem", // Deprecated in v5.0.0, removal target v6.0.0. |
There was a problem hiding this comment.
spacing.11 shows up 9 times across 5 Calcite Components (input, input-text, input-number, stepper, tab-nav). This is the hardest one here to replace with a semantic token since 2.75rem is a spacing interval that we'd rather not include semantically, but I'm talking it through with the team now.
There was a problem hiding this comment.
Updated the deprecation note to show a placeholder for now
There was a problem hiding this comment.
All the instances mentioned above should probably be using size tokens rather than space like Aaron mentioned in the other comment. We can use --calcite-size-lg to replace spacing.11 in the linked examples.
However, I'm thinking that doesn't mean it's a good general recommended replacement option for a deprecation message here (going from spacing -> size that is). Are we okay with just deprecating without a replacement since we have a plan for the instances in our components?
There was a problem hiding this comment.
Could we have the deprecation message or migration note suggest the size token if it is applicable instead of recommending it as a direct replacement? Something like the following?
spacing.11was incorrectly used in size contexts, so we recommend using--calcite-size-lginstead.
If that doesn't work, it should be fine to deprecate with no direct replacement as long as we provide sufficient details about the removal to users.
There was a problem hiding this comment.
If I'm understanding what's happening correctly then the wording Franco suggested is pretty much good to go.
Maybe with some small tweaks:
// Deprecated in v5.0.0, removal target v6.0.0 -
spacing.11was used incorrectly for sizing, use--calcite-size-lginstead.
Or since the message will be on the token already we could omit the token name from the deprecation message.
// Deprecated in v5.0.0, removal target v6.0.0 - Not intended for sizing, use
--calcite-size-lginstead.
There was a problem hiding this comment.
Love it! If we get this in for the patch today March milestone, would the version technically be 5.0.1 5.1.0?
There was a problem hiding this comment.
Assuming that the first hypothetical breaking change for the tailwind-preset package would be 2.0.0, would we go with this?
// Deprecated in v1.1.x, removal target v2.0.0 - Not intended for sizing, use --calcite-size-lg instead.
Or if we are okay with basing the removal on a different package, then maybe:
// Deprecated in v1.1.x, removal target Calcite Components v6.0.0 - Not intended for sizing, use --calcite-size-lg instead.
|
I'm skipping visual snapshots now since there were no issues found after the initial changes were made: UI test link |
Related Issue: #10052
Summary
No values should be changing.
Deprecations: (versions pending - see comment thread)
deprecates
spacing.[2.5]with note:Deprecated in v#.#.#, removal target v#.#.# - use `--calcite-space-sm-plus` instead.deprecates
spacing.[4.5]with note:Deprecated in v#.#.#, removal target v#.#.# - No longer needed.-no longer used in any Calcite Components
deprecates
spacing.11with note:Deprecated in v#.#.#, removal target v#.#.# - Not intended for sizing, use `--calcite-size-lg` instead.-
--calcite-size-lgplanned to replace all instances ofspacing.11deprecates
spacing.13with note:Deprecated in v#.#.#, removal target v#.#.# - No longer needed.-enhancement planned to replace instance of
spacing.13intabsNo deprecation needed since the values are the same of tailwind defaults and should still function the same
spacing.[0.5]spacing.[3.5]spacing.9Other details:
For reference, these are the currently in-use (by Calcite Components) tailwind utils that semantic tokens could match:
And these are the remaining in-use tailwind utils for which there are currently no semantic alternatives. The first few on this list are strong candidates for new semantic
spacetokens that we may need in the future.