-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename edit-post__fade-in-animation and unify keyframe definitions #65377
Conversation
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
// These keyframes should not be part of the _animations.scss mixins file. | ||
// Because keyframe animations can't be defined as mixins properly, they are duplicated. | ||
// Since hey are intended only for the editor, we add them here instead. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the changes introduced by this PR, there may be some duplication — but IMO it's a much better compromise than all the potential downsides listed in #64580 (comment)
Size Change: -61 B (0%) Total Size: 1.77 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good 👍
|
||
animation: __wp-base-styles-fade-in $speed linear $delay; | ||
animation-fill-mode: forwards; | ||
@include reduce-motion("animation"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are your thoughts on the continued usage of this mixin? For new code, should we just write out the media query like we're doing in the components package?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the approach that we're taking in components package, ie. "only add animation styles if the user does NOT prefer reduced motion".
Having said that, I would prefer not to make such a change here for two reasons:
- consistency: if make such a change, we could consider doing so at the project level?
- the
reduce-motion
mixin sets durations to0s
, which is technically different from not having an animation at all. For example, I'm not sure how animation and transition events would fire across browsers, and that could introduce unexpected behaviors.
To sum it up: I'd be up for making the change, but I'd make it separately from this PR and gradually:
- refactor usages one by one to
@media not (prefers-reduce-motion) { /* animation code /* }
, test for breaking changes - when all usages are migrated, deprecate the mixing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree with @ciampo, worth doing but with precaution
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That said, regarding this:
the reduce-motion mixin sets durations to 0s, which is technically different from not having an animation at all. For example, I'm not sure how animation and transition events would fire across browsers, and that could introduce unexpected behaviors
I'm not 100% sure, but I can't see how a duration of 0 would be effectively any different from disabling the animation itself, other than if there's a delay in one of them or something like that which I doubt. Btw, now that I think about it that approach (setting duration to 0) was flawed in that way. A delay would still affect it. One more reason to migrate away from that pattern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW the duration is set to 1ms, which may be even more different 😅
What?
Extracted from #65203
Rename the
edit-post__fade-in-animation
to a more generic name (deprecating the previous name), unify underlying keyframe definitions to be under the same package, and add an equivalent "fade out" mixin.Why?
See #64580 (comment)
How?
edit-post__fade-in-animation
toanimation__fade-in
, deprecated old nameanimation__fade-out
Testing Instructions
Make sure that the
Modal
component's enter animation (fade in) works as on trunk, both in Storybook and across various parts of Gutenberg.