We Keep Coding

What is the purpose of Angular animations?

I've been wondering for some time now why should I use Angular animations over CSS animations. I see few areas one might consider before using them:
Performance
In the first step I found this question which deals only with performace side of things. The accepted answer is not satisfying for me because it states that one should use CSS animations wherever possible so that optimizations like running the animations in separate thread can apply. This doesn't seem to be true, because Angular documentation states
Angular animations are built on top of the standard Web Animations API and run natively on browsers that support it.
(emphasis mine)
And when we look at Web Animations API Draft we see that the same optimizations can apply to Web Animations as to CSS specified in sheets.
While it is possible to use ECMAScript to perform animation using requestAnimationFrame [HTML], such animations behave differently to declarative animation in terms of how they are represented in the CSS cascade and the performance optimizations that are possible such as performing the animation on a separate thread. Using the Web Animations programming interface, it is possible to create animations from script that have the same behavior and performance characteristics as declarative animations.
(emphasis mine again)
Apart from some browsers like IE don't support Web Animations, is there any reason to use either CSS declarations over Angular animations or vice versa? I see them as exchangeable performace-wise.
More control over the animations
This might look as an argument for Angular animations, because you can pause animation or use JS variables with it etc., but the same is true while using eg. CSS animation-play-state: pause or using CSS variables specified in JS, see documentation.
Now I can see it might be inconvenient to set the CSS variables in JS code, but the same is true while using Angular animations. These are typically declared in #Component animations field and don't have, except for via the animation state data bound property, access to instance fields (if you don't create your animation via AnimationBuilder of course, which btw is also not very convenient or beautiful either).
Other point is, with Web Animations API it is possible to inspect, debug or test the animations, but I don't see how this is possible with Angular animations. If it is, could you please show me how? If it isn't, I really don't see any advantage of using Angular animations over CSS ones for the sake of control either.
Cleaner code
I've read for example here a paragraph stating that separating animations from "normal" styles is actually separation of behaviour and presentation. Is really declaring animations in styles sheets mixing those responsibilities? I saw that always the other way, especially looking at CSS rules in the #Component animations gave me a feeling of having CSS declarations on one too many places.
So how is it with Angular animations?
Is it just a convenience utility to extract animations away from the rest of the styles, or does it bring anything worthy feature-wise?
Does a usage of Angular animations pay off only in special cases or is it a convention a team chooses to go all the way with it?
I would love to here about tangible advantages of using Angular animations. Thanks guys upfront!

So I did some research and although I didn't find any argument for nor against Angular animations performance-wise (as already stated in the question above), there are very good arguments to use Angular animations feature-wise which should be good enough for purists who want to have CSS only in sheets, at least in certain cases.
Let me list some useful features where each alone makes a convincing case for Angular animations. Most of them can be found in Angular animations documentation:
Transition styles - these styles are only applied during transition from one state to another - only while an element is being animated, and one uses them like this:
transition('stateA => stateB', [style({...}), animate(100)])
Trying to do the same with CSS only might not be as expressive in terms of which previous state led to the next. And it can be outright clunky if the animation has to differ based on the initial state but the end state is the same.
The void state together with :enter and :leave aliases (void documentation, :leave and :enter documentation) - Let you animate elements being added or removed from the DOM.
transition('stateA => void', animate(...))
This is very cool because previously, although it was easy enough to animate the addition, the removal was more complicated and required to trigger animation, wait till its end and only after that remove the element from the DOM, all with JS.
Automatic property calculation '*' (documentation) - Allows for performing traditionally difficult animations like height transitions for elements with dynamic height. This problem required either to set fixed height on element (inflexible), use max-height with tuned transition function (not perfect) or query element's height with JS (potentially causing unnecessary reflows). But now with Angular it is as easy as this:
trigger('collapsible', [
state('expanded', style({ height: '*' })),
state('collapsed', style({ height: '0' })),
transition('expanded <=> collapsed', animate(100))
])
And the animation is smooth and "complete" because the actual height of the element is used for the transition.
Animation callbacks (documentation) - this is something that wasn't possible with CSS animations (if not maybe emulated with setTimeout) and is handy eg. for debugging.
Unlike stated in the question, it is actually possible to use instance fields as params in Angular animations, see this question. I find it much easier to use than manipulating CSS variables through DOM API as shown here on MDN, not mentioning the limited support in some browsers.
If you need any of the features listed above, Angular can be a better tool for the task. Also when there is many animations to manage in a component, and this is just my personal opinion, I find it easier to organize animations the Angular way than have them in sheets, where it is harder too see the relationships between them and various element states.

GSAP Performance & Structure

GSAP claims to use HTML5 to perform outstanding animations for web use, but says clearly in the their article on Greensock.com that it does not use the canvas frame work in html5. It is clear that they are using Javascript from the provided script, but it is very confusing to interpret. In what other way would they use html5 animations without the canvas? And if they do use pure HTML5 does this mean that HTML5 animations are significantly faster than CSS, jQuery, and Javascript?

There's not such thing as "html5 animations".
There are, mainly, CSS3 animations (with either CSS transition or CSS animations) and Javascript animations.
CSS3 animations are generally well optimised (with a few quirks) but lacks support (old IEs) and flexibility (you'll have to use JavaScript to tweak them.) They're best for hover effect (with transitions) or basic animations.
JavaScript transition used to be based on a setInterval. A timed loop, and inside this loop the styles are changed. JQuery does this, and not very well.
Recently, Window.requestAnimationFrame() was introduced to replace these setInterval animations. Support is limited (old IEs), performance is top notch (because the browser can skip frames), and it's always style updates inside.
What GSAP does is using this requestAnimationFrame() while optimizing for less repaints and adding a lot of useful features (reverse, timelines, stagger...) On basic animations, you can achieve the same performances with CSS3 or your own JS code... if you know what to do.
There are also others animations (canvas, svg... event webgl) but more specialized.

In my limited experience with GSAP, and during some discussion with the developer of Velocity.js, it seems that GSAP has some very convoluted code that is quite difficult to interpret; I'm not sure if this is because they're purposefully obfuscating the code or that they do some very crazy optimizations... Maybe a bit of both. They may have also taken native code and created a Javascript implementation. In any case it makes reading the source quite difficult to do.
As far as your question about HTML5 animation, which I'm taking to mean animating objects on the DOM without Javascript, if you're using a compliant browser, you can achieve many animations via the CSS transform and transition property, the former being about DOM object transformations (moving it 10px to the left) and the latter being about how the object moves as it transforms (does it move linearly over a period of time, or use a user specified cubic bezier curve to describe its motion?). With current compliant browsers, the main difference in these properties besides vendor prefixes like -webkit- and -moz- is small. What this means is that you can reliably get animations on DOM objects across those browsers if you take case of the prefixes. You can use these transform/transition properties to manipulate almost any DOM object property.
In terms of speed, it depends. CSS animation is generally the faster between it and Javascript, but it lacks control because it's hard/impossible to manipulate certain properties like key frames. Javascript animation is slower, but using a good library makes this difference negligible and in some cases Javascript animation can be faster. It really depends on what you're trying to achieve. CSS and newer Javascript library animation is considerably faster than jQuery due to some reasons listed here.
*: Of course some browsers, like IE9 and 10, while being relatively compliant, do miss some properties and have quirks about their rendering engines.

Javascript animation: IE vs other browsers

Before I launch into the specifics of the issues I am facing, I just need to ask: Is it a mistake to use IE8 as the reference for building a website, particularly one that uses JavaScript animation? I ask because I have written a fairly simple animation page, mostly from scratch, even with my weak grasp of HTML and JavaScript languages, using IE8 to monitor the progress. I have tweaked the code so that it works just fine in IE8 (compatibility mode turned off), but when I tried it in Safari and Chrome, it does some weird hiccuping in the animation.
I find a lot of questions with the opposite problem: that it works well in everything but IE. So I am wondering, should I be using a different browser for my reference? Or is there a better approach to make it compatible with all browsers? It's so frustrating (as I am sure most of you will agree) to have to deal with the different interpretations of the different browsers.
Thanks for any help!
p.s. I have not coded yet for Mozilla.

Using ie8 as a reference from a performance point of view is not a bad idea, since it has weak js and rendering performance. Using ie7 is even better.
Cross browser compatibility wise, it doesn't matter what you use - unless you use a crossbrowser library like jQuery as your base for the animations you will have to write specific code for the various js and render engines.
Even if you use a library like jQuery, you will still run into rendering issues since the various html/render engines are different across browsers. chrome/safari uses webkit, firefox uses gecko etc.
The only way to do it right is to start your project by defining what browsers you wish to support and then test what you do in all of them while you are developing your code.

If you're doing animations, I encourage you to take advantage of css transitions instead of controlling the elements via javascript - you'll have an opportunity to take advantage of graphics hardware as well as more efficient drawing of pixels in general.
If you need to still perform animations in browsers that don't support those css transitions ( some in ie9, none in ie6-8) then you can use a tool like modernizr to detect what's available and control those elements in the event those features aren't available.
Typically, the animations are extra - so I've had good success in ditching the animations for IE users - if you're making slow, javascript driven animations just to work for IE users, you're punishing users that are using better browsers.
Just my $0.02 of course

Add style elements in CSS

I want to make my own custom CSS elements that will be handled by a js file of mine. Is this possible?
Here would be an example:
div {
rounded-corners:15px 15px
}
And then use Javascript to apply the styles for each browser for rounding corners.
Is there a way to do something like this?
EDIT
The point isn't to add a common support for browsers. I want to implement my own CSS things.

The answer is "no". While it is possible to easily get style values from stylesheets in Internet Explorer by accessing the currentStyle property, like so:
alert(myDiv.currentStyle['rounded-corners']);
//-> "15px 15px"
...other browsers don't support the currentStyle property, opting instead to support the W3C standard window.getComputedStyle(). getComputedStyle() doesn't include "expando" style properties in the outcome, which means your only option would be to iterate over the rules in each stylesheet instead, which could be an expensive procedure depending on how many stylesheets and rules you have. Obviously, you also lose out on the browser's cascading/computing.

IE9 and the latest versions of Firefox and Chrome all handle border-radius anyway.
And you can use CSS3 Pie to add support to older version of IE. No need to write your own script.
EDIT: I suppose you could write your own version of CSS3 Pie, but why would you want to?

You may want to look into SASS/SCSS or LESS, which both offer "mixins". These act like functions in CSS, and should let you do what you want. LESS at least can be made to work client-side through Javascript; I suspect SCSS can too.

CSS already has a property for rounded corners, called border-radius.
This is supported by virtually all browsers in current use. The only exception of any significance is IE8 and earlier.
The good news in this case is that IE8 can indeed be programmed to work the way you're asking. Other browsers cannot, but IE can, and this is lucky, as it's the one browser that needs it more often than most.
So the direct answer to your question is "sometimes". Most browsers drop the styles they don't support, but IE keeps them. It obviously don't do anything with them, but you can access them via the DOM, which means that you can do what you're asking.... but only really in IE.
In the case of rounded corners, there is already an excellent Javascript-based hack for it called CSS3Pie. This is open source, so you can examine their source code to learn how it's done.
The CSS3Pie code is quite complex though, so if you want a simpler example to work from, take a look at this older script which does the same thing a lot more simplistically. Easier to read, but not as functional. For real life use, use CSS3Pie, but for learning, this one is a better starting point.
For working with IE, I would suggest following the examples in these scripts to achieve what you're asking. For other browsers, you will have a much harder time.

Using HTML Canvas for UI elements?

I have a couple of UI elements such as buttons in my web application. I was going to use CSS3's transitions to animate the transition from one background-image to another. I figured out that it's not possible with the current transitions draft at least. So, I was wondering if it would make sense to use Canvas as the button. I'm sure it can handle events, so, I see no problems here. Are there any?

Other than the fact that it's not supported in IE, no.

canvas is not supported in Internet Explorer. Also, canvas animations render very slowly on PCs with little CPU power.
Unless you are writing something that is for a specific target audience (say internal users with Firefox and dual-core cpu) I think you should avoid using canvas for now...

I came to conclusion: using Canvas for UI elements is not a good idea.
For example, if you create a select-box using Canvas, how is the list going to appear in the top of other HTML elements?

Use raphael.js (MIT license) - it give you canvas-like API using SVG (and VML for IE) and works in all amjor browsers including IE6. And its fast (not too slow even in IE)