DS-692 Animation Tool Set

[MarcinMr]

Jira

https://pegadigitalit.atlassian.net/browse/DS-692

Summary

Animated classes with keyframes were added to packages/global/styles/animations.

Details

There were created fade, bounce, zoom (ins/outs) combined with slide effects (top, bottom, left, right) + modifier classes controlling the cascading appearance of elements and delays options.

fade

• fade in / out / in-up, out-up / in-down, out-down / in-left, out-left / in-right, out-right

zoom

• zoom in / out / in-up, out-up / in-down, out-down / in-left, out-left / in-right, out-right

bounce

• bounce in / out / in-up, out-up / in-down, out-down / in-left, out-left / in-right, out-right

---

Test pages were created in the tests/animations folder for experimenting.

How to test

Check if animations work properly by adding specific classes to the elements considered to be animated. Make sure the performance of animating elements is sufficient.

[MarcinMr]

@mikemai2awesome

Could you please have the first glimpse of that? I created a few fades classes that can be added to the elements that wanna be animated.

It isn't easy to make the performance efficient on every browser engine. I used that page -> https://csstriggers.com/ to learn about how different browsers behave with CSS triggers. The main rule is not to animate anything which triggers layout for example: padding, margins, width, etc. And animate only those which trigger the "composite" (the safest way to not affect the performance in a bad way).

So in our case, I used opacity, and transform which are the best properties for animations. But... not for every browser. For example, changing transform and opacity on the browsers which are based on the "WebKit" (Safari) triggers every three things: layout, painting, and composite which is bad for the performance.

The other thing is if we don't wait for loading the page our animations also aren't quite good. For example on this video titles are appearing not in a smooth way

gallery-safari-no-wait-for-load.mov

Performance on the gallery test page without waiting for the load

Here the green graph(frames per second) is very bumpy because animations start together with the other processes causes that the graph isn't smooth and frames per second aren't consistent

This is why I added a draft js script to test that.

Performance on the gallery test page waiting for the load(with the script).

Here is the difference. Animation waits after the previous things are loaded and then triggers itself. Here frames per second are consistent and equal 60fps which is good.

So even if we want to animate things right after a page load (for example after internal linking to another page) I believe we should also wait till heavier processes are loaded and then trigger the CSS keyframes.

@mikemai2awesome Please take a look at this and let me know what do you think.

FYI @colbytcook

[mikemai2awesome]

@MarcinMr Good job! I only have a few inline comments and we'll discuss performance with the team in dev huddle.

[mikemai2awesome]

@MarcinMr I reduced cascade to 25 to keep the file size down. We will need to figure out how to do this better later on.

[danielamorse]

@MarcinMr I made a separate PR so you could review my suggestions. Feel free to merge that PR if it all makes sense: #2428

This all looks great, just had some notes on the cascade animation and the demo JS. See inline comments.

cc @mikemai2awesome @colbytcook

[danielamorse]

My JS edits have been merged and everything else looks great.

I just merged in the latest from master to fix the failing build (chromedriver).