refactor(alert, dialog, sheet, tree-item): swap to a unified animation curve#14038
refactor(alert, dialog, sheet, tree-item): swap to a unified animation curve#14038
Conversation
github-actions
bot
added
the
refactor
Elijbet
force-pushed
the
elijbet/12669-unified-curve-token
branch
4 times, most recently
from
63dd839 to
99d1182
Compare
Elijbet
force-pushed
the
elijbet/12669-unified-curve-token
branch
from
99d1182 to
6b60cec
Compare
| // --calcite-internal-duration-factor | ||
|
|
||
| $easing-function: cubic-bezier(0.215, 0.44, 0.42, 0.88); | ||
| $easing-function: ease-in-out; |
There was a problem hiding this comment.
@chezHarper
Could you run this PR and compare alert, block, dialog, sheet, tree-item with the existing animation to see if this is acceptable.
There was a problem hiding this comment.
Are there any plans to introduce animation-related tokens? If so, when implemented, we could drop this Sass var in favor of the token (and use it directly wherever needed).
There was a problem hiding this comment.
Not sure if we've discussed it yet, but I think it makes sense to have semantic tokens for these. cc @matgalla
There was a problem hiding this comment.
100% we'll want animation tokens 👍 It will be best to add them when we have a solid idea of the range of animation-related variables that are needed across components. My main concern is making sure the semantic animation tokens are appropriately named.
For easing values, do we expect to use a single value (like this ease-in-out here) across most components? If so, then a default calcite.animation.easing would be appropriate, and we could make that sooner rather than later.
But if we anticipate using different easing values for different components based on size, for example, then we may want multiple like calcite.animation.easing.sm|md|lg (or similar). In that case, I'd prefer to wait until we know what the distinction between each easing's use case would be.
@chezHarper are we in a place where we could pin this down and create some tokens that would reflect the varying animation use cases across our components?
There was a problem hiding this comment.
@chezHarper is that approval of animation tokens in general, or specifically for one of the approaches to easing tokens I mentioned?
These are options as I see them (for easings specifically):
- A single 'default' that all components will use (
calcite.animation.easing) - Varying easings based on component size (
calcite.animation.easing.sm/md/lg) - Something else
jcfranco
left a comment
jcfranco
left a comment
There was a problem hiding this comment.
Code changes LGTM! Good to merge once @chezHarper approves.
| // --calcite-internal-duration-factor | ||
|
|
||
| $easing-function: cubic-bezier(0.215, 0.44, 0.42, 0.88); | ||
| $easing-function: ease-in-out; |
| // --calcite-internal-duration-factor | ||
|
|
||
| $easing-function: cubic-bezier(0.215, 0.44, 0.42, 0.88); | ||
| $easing-function: ease-in-out; |
5 participants
Related Issue: #12669
Summary
Swap to a unified animation curve.
Right now we have two different sources of truth for the easing curve. Tailwind animation utilities use
ease-in-out, SCSS transitions use$easing-function: cubic-bezier(0.215, 0.44, 0.42, 0.88).We need to pick one canonical easing token, and since the
$easing-functionvar has been inherited from a fazed out dependency, I'm swapping it with a default to align with the rest of the components.