Animation Sequencing 3

 

One of the issues in previous versions of this animation is that I was using the wrong names for the CSS animation functions– for example, transition-name instead of animation-name.  Er, duh.

So I fixed that problem, using the long form version of function naming for clarity.

Also, I gave each SVG element its own keyframe rule — instead of having the elements all share the same one —  so the browser is clear as to what is supposed to happen.

Previously, I had assigned all the “leaf” animations to the same keyframe as an optimization, counting on the browser to know how to automatically clone and reuse each keyframe in its own execution context for each associated SVG element.  It kind of worked (see pic below), but didn’t — and I am going to circle back eventually on this reuse of keyframe rules idea, and see if I can make it work correctly.

svg animation inspector
See below for more info on user agent animation inspectors

I also made the animation timing linear, so there is no confusion as to impact of the timed delays.

Finally, I set the iteration count to 1. After all: how can you declaratively sequence a keyframe rule 2 to start after a keyframe rule 1 ends when rule 1 never actually stops? This is an interesting question that requires further investigation.

So now the sequencing is correct, but there is no “animation chaining” — by which I mean everything starts over again, in the correct sequence, after the 4 keyframes complete their execution. It goes around once, and that is it.

Finally, you might have noted that the leaves fade out in sequence, after they have executed.

This make sense, I guess, since JS is single-threaded: you cannot (to my knowledge) for example, launch keyframe animations in parallel.

I also took a look at what was going on using the Chrome Animations Inspector.

animation inspector
Look familiar? This is just a regular animation timeline, the kind of you see in many graphical animation apps — built right  into Chrome!

 

Here is the same thing, as implemented in the Mozilla Developer browser.

 

svg animation
Notice where (in terms of elapsed secs) each keyframe rule ends

 

Just for laughs, here is what my go-to SVG reference book, Using SVG3 with CSS3 & HTML5 [Bellamy-Royds, et al]. says on the topic:

 

“You cannot easily coordinate one animation effect to start after another animation finishes. You either need to string them all together in a single @keyframes rule set, or adjust the animation-delay on the second effect to always match the duration of the first effect — and then adjust the delay on a third effect (…) and so on.
CSS variables and calc() will make this easier, but it can still fussy for long animation sequences.”

Hmm.

Examples would have been nice.

I’ll work on this problem a little further with some fancier CSS, then move on to develop a SMIL implementation (btw, am really confused at the moment as to whether SMIL is deprecated or not: see this excellent article),  followed by a JS one (probably using GSAP).  The idea is to see which implementation gives you the most control with the best performance using the least amount of code.

 

Before continuing, let’s review this animated SVG example,  here are the (high level, i.e., no details as to timing) requirements:

 

yellow circle with green border, no logo

leaf 1 fade in

leaf 2 fade in

leaf 3 fade in

leaf 4 fade in

everything fades out simultaneously

repeat ∞

 

If you want to try out the Animation Inspector on your machine with this SVG example, just download this .pdf file, then convert it using this free online utility, then change the file extension to .htm and run the file on your fave browser. Remember to always use a virus checker before extracting a file on your computer!

#  #  #