Is there a process, tool, prefered method to describe css animations, forwards and backwards, before you start coding them? I lose a lot of time describing the animations and/or picking up feedback for them and then, if someone did not visualize them correctly or had a different idea, we have to make changes, which remain as vague as before, until you finished coding them.
One word for you: storyboards.
I need to write an article about this. But here's what a good storyboard looks like as a jumping off point:
Notice: two colors, one for actions, one for animations. The description below each wireframed panel describes what moves when why.
You'll work off these, and things are bound to change as you enter dev, but for documentation, you'll want to add duration, easings, and properties. These are fantastic design artifacts for communicating to dev and deferring to when incorporated in design documentation.
If you are trying to communicate with a developer, you might look to the documentation of whatever they are using to code the animations. For example, you could describe CSS animations in terms of keyframes, repetitions, timing, delay, etc.
I've always preferred to prototype. Using something like Axure or Hype Studio, you can approximate many animations. Even Apple Keynote can do a lot of animations. You could use drawings on paper to show the developer what you want, too.
If it's a really unique behavior, you could do an Axure prototype, as suggested above, or a storyboard to show each step of the animation. Developers are great at following instructions, but if you don't provide really detailed instructions, don't be surprised when you get something different than what you had imagined.
I find the quickest method is to prototype the desired effect in a tool such as Axure, Framer JS, etc. and then record an animated gif using LICEcap.
Here's an example from a recent "Streaming Activity Panel" specification I completed using Axure and LICEcap:
Then it's up to you to decide how much narrative to provide along with the actual animated image. I tend to under-specify animation timings (e.g. 300ms) and animation transition timings (e.g. ease in/out), since such details are going to be subject to scrutiny during design review.