Last week I was asked to evaluate the technical impact of transferring a (rather simple) animation to html5 and css3. So I searched around, looked at some css3 animation demos and figured that with a few minor adjustments it wouldn't pose any real technical challenge. Before I finalized my answer I waited a minute to reconsider the problem, as it felt as if I had somehow missed the most essential part of the question.
The company I work for wanted an animation visualizing and explaining its main ideology (define - design - realize - optimize). There was a story board detailing the different objects, animations and links between objects. The animation was kept pretty basic (nothing organic, just simple mathematical animations) and thus html/css was considered for the implementation. Not in the least because it would also we a great showcase of our front-end skills.
Technical challenges aside though, the real question was whether this animation would actually be a valid use case for html/css animation. After all, it's not because we could do it with html/css that we should do it. I was instantly reminded of the time people made simple websites in Flash (just because they knew how to use the tool) and that was clearly not the message we wanted to send to our potential clients. It wasn't just about showing our technical proficiency, it was also about motivating we could use the right tool for the right challenge.
css animation vs video
Before making any final claims about the challenge I was given, I had to figure out the differentiating factors between video and css animations. While there is definitely a gray area between the two solutions, there are also some good differentiators that will help us choose between the two.
A video is mostly presentational. It gives you a nice and guaranteed aesthetic experience, possibly (but by no means a given) also some actual content. On the other hand, video isn't all that semantic and doesn't allow for much interactivity without hacking yourself a way around a myriad of limitations. Style is clearly more important than content.
The problem with css animation is that quality isn't guaranteed. Depending on the processor load, machine power and complexity you might end up with a stuttering presentation. On the other hand, you can create a semantic equivalent of your animation so it becomes more than just a sequence of visual frames. You can actually unlock your story to people who aren't able to watch the animation itself.
using the differentiators
If presentation matters most then I would definitely opt to use video. There aren't as many limitations and quality playback is more or less assured. On the other hand, if you want interaction and/or you benefit from making a semantic equivalent of your animation than html/css becomes a viable option.
back to the real world
Of course this is a very theoretic approach to the problem. There are other factors that may influence your final decision, but they are variables rather than best practices and they are sure to change over time. It's not that they are not important, in some cases they can actually be critical, but they shouldn't be your primary concern when faced with this kind of choice.
File size, streaming possibilities, fall-back mechanisms and responsive behavior need to be taking into account and can still overthrow your initial choice. That's okay, as long as you can use them to motivate your choice when going against standing best practices. Just picking a method because it's what you do best or because it's cool and everyone is doing it these days on the other hand is lazy and just plain stupid.
Currently we are still investigating the fall-back quality in browser who don't support css animation. If these tests guarantee us a sufficiently high quality we'll be starting the development of our html/css animation. I have a pretty good idea of how to go about this, so hopefully I'll be able to share a demo in the near future.
The bottom line of this article is not so much about video and css animation though, it's about considering the tools you use for certain challenges, first and foremost thinking about what a tool is supposed to be doing instead of what would be easiest for you to develop. There are always real-world factors that might influence your original decision, urging you to go against what you know is right, but that's probably what separates professionals from amateurs.