[RFC] More consistent definitions and better accessibility

[brc-dd]

I would like to highlight a few things that can be fixed in upcoming versions.

1. Back entrances

   • At 0%, there is stuff like translateY(-1200px) scale(0.7) with opacity: 0.7. Does these magic values (1200, 2000, etc.) work on all screen resolutions (especially 4K screens or like)? By "work", I meant it is an entrance, it should come from off-screen. Why not define these in terms of vh/vw/%? Anyway, I think at least opacity: 0 can be maintained on entrances.

2. Back exits

   • At 100% (animation complete), the element is still visible because opacity is not 0. Also, there is inconsistent convention, at some keyframes there is from , to at others 0%, 100%. A project wide convention on these would be nice I guess. Also at many places from/to is not necessary (as done in zoom animations), that can also be made consistent.

3. Sliding entrances/exits

   • There is a unique thing that I noticed here, the keyframes have visibility properties in them. Only these animations actually inject/remove elements from the accessibility tree. I think this can be tested on all entrances/exits.

4. Accessibility

   • Why is transition-duration set to 1ms? Doesn't only setting animation-duration to 1ms does the job and completes the animation as soon as possible?

5. Bounce Entrances

   • There is code like this:

     from,
     20%,
     40%,
     60%,
     80%,
     to {
       animation-timing-function: cubic-bezier(0.215, 0.61, 0.355, 1);
     }

     Why not simply do this instead:

     .animate__bounceIn {
       animation-timing-function: cubic-bezier(0.215, 0.61, 0.355, 1);
     }

6. 3D transform functions

   • In the code, I can still see use of translateX, etc (in headshake for example). The major part is although is using translate3d and friends. This can also be modified.

7. Jello

   • skewX(ax) skewY(ay) can be changed to skew(ax, ay).

[eltonmesquita]

Hey @brc-dd , thanks for the proposal they make sense, but first a few explanations:

1. Back entrances:
   Makes sense, but the width of the screen is not the only variable in this case. Imagine a small screen like a mobile that will have around 320px of screen width to translate with the same animation-duration as the one with 4k resolution. The small screen will have a very slow animation and the 4k one will have a very fast one. That's why we use magic numbers. About the opacity, the dev can always set it on their own and use the animation-fill property to control the initial and final states. It's a bit more work, but it's more flexible

2. Same as 1. Yeah, makes sense to have some standards. As animate.css has a very long history some (from a time when web animations were a novelty) we had to do lots of weird things to make things work properly in every browser because there was every sort of nasty bugs out there. But yeah, we're in better times now and we should improve it.

3. That was probably due to some weird bug somewhere in the past, so we could ditch them out now, I guess. To be honest, I'm not sure that accessibility wise it's better to set the visibility to hidden when the opacity is set to 0 or not. I'll have to have a look at that. Any material about that is welcome!

4. Have a look at Reduced-Motion: Replace animation: unset and transition: none with 0-length durations. #931

5. Yeah, we can improve that, but we have to keep in mind that many devs only use the keyframes, so we would break animate for them.

6. PRs are welcome!

7. PRs are welcome!

[brc-dd]

@eltonmesquita Yeah, I agree on that timing stuff. So can we at least fix the numbers? I mean, like have something that's off-screen on even 4k resolutions and use them throughout the project (preferably via CSS variables).

That visibility thing was probably introduced because omitting it would make the element visible, and using opacity: 0 at the end would have made sliding animations the same as fading ones. And my argument regarding setting visibility: hidden on exit animations is -- an element with an exit animation is always visually hidden, but for those who are using assistive technologies like screen readers, the element adds noise. Adding visibility: hidden will fix this without any visual impact on the sites as it doesn't remove the element from DOM tree, i.e. it still occupies the space (like it occupies now with just opacity: 0).

Regarding the fourth point, I think you misunderstood that. I wasn't saying to use animation: unset. I was saying why set transition: none or transition-duration: 1s at all? The library itself never adds any transition in any of the present classes.

And the fifth, there are a bunch of other animation classes where similar things are present. transform-origin, animation-timing-function, backface-visibility, etc. are there which are applied in the classes, while they all can be put in the keyframes as all of them are animatable properties. So should we move them to their corresponding keyframes?

And yeah, happy to contribute. I had actually fixed them in one of my Tailwind plugins. It won't take too long to backport the fixes.

[simeyla]

No special accommodation for pixels in 4k is needed (everything is specified in 'logical pixels' - not device pixels). So everything happening with device pixels is just doubled compared to a 1920x1080 screen. It makes no difference to definitions of animations and distances. Just in the same way as you don't have to do something different from an iPhone with 2x pixels to one with 3x pixels.

I came to this post because of my concern about animations with translateX tranforms with magic numbers like 2000px. While it's fair to say that using 100vw instead of 2000px would make the animations slower on a smaller screen the problem I'm encountering is that since most of the animation now occurs offscreen you lose the nuances of the 'easing'. And a one second duration is meaningless if 750ms of the animation occurs off screen!

If something is 'bouncing' or 'easing' over a distance of 2000px then the bouncing or easing effect is spread out over that distance. If I have an image being bounced off my 428px wide phone to 4 screens off to the right then I'm going to miss a lot of that effect.

The effective speed may be technically more consistent but suddenly the distinction between the different animations is lost.

I'd much rather see the 2000px set as an additional variable instead so I can adjust it to 100vw or 200vw myself and change the durations accordingly.