Differences and Similarities Between Svg and CSS3 Animations

Differences and similarities between SVG and CSS3 animations?

Ok. I have a whole presentation with an introduction to CSS Animations and A little on SVG.

But here are the oversimplified essentials:

• The CSS Animation spec (per se) is just equipping you to declare "key frames" or multi-step transitions between Styles.
• "Styles" in CSS3 includes "Transform" which specifies the scale, rotation, skew and position offset of a page element.
• It's possible to "Transition" between styles, and specify the time and pace of that transition, to the extent, even, of declaring a cubic bezier timing function.
• Combining Animations, transitions and transforms gives you an easy, declarative way of moving and transforming ANY page element (an img, a div, a video etc.) in a very rich way, that also progressively degrades nicely in older browsers (as long as you're sane about things).

BUT every element is essentially treated as an undifferentiated 2d rectangle for the purposes of animation, so its really all about animating sprites. At Sencha, as you've noted, we've even built a whole CSS Animation tool around this. And you should take a look at some of the demos there because it shows that you can really do a lot with the small set of primitives that CSS gives you. - Product Discontinued.

SVG Animation can be performed using the built in SVG animation capabilities (animate, animateelement etc.), SMIL (a declarative animation description similarish to CSS Animations) or JavaScript), has a richer set of capabilities than CSS Animation, but only because you're creating SVG Objects and changing their properties. You can't use SVG "animation" to, for example, animate an existing piece of HTML.

But it's also much richer. The biggest gain in SVG is that you're declaring drawing paths and fills with great flexibility (lines, arcs, quadratic arcs, cubic bezier arcs etc. etc.) and you can change the value of these properties over time using transforms and key splines (similar to timing functions in CSS Transitions)) This allows you to perform "rigging" animation rather than sprite animation. (I'm not an animator, I'm just using the terms I think are appropriate). So you can actually draw things like this cat walking across the screen, using line animations impossible to perform with CSS Animation (or impossible to perform for people of reasonable sanity - if insane people want to declare large numbers of zero height divs with border radii and use transforms to simulate arcs, then it's a free country.)

On the other hand, SVG is a PITA if you're writing it unassisted (verbose XML style with XHTML dtd). I'd highly recommend Raphael if you're a JavaScripter - Raphael has the benefit of degrading to VML vector graphics in older IE. SMIL (declarative animation for SVG) is a nice idea but it's not properly supported in many places. Also many browsers don't properly support SVG and those that do, often support it incompletely, particularly when you try to animate properties.
Update: there are many more updated animation libraries nowadays including snap.svg, greensock and others.

And there's no SVG support in Android 2.x, so if you want web animations that work on phones you're stuck with CSS Animations.

Having taught myself the basics of SVG animation in order to develop the intro presentation linked at the top, I can give a hearty thumbs down to hand-writing SVG. It's hard to remember, it's non-intuitive and because its XML, it tends to either work completely or fail completely, making it frustrating to debug.

Between SVG and canvas, which is better suited for manipulating/animating several images? Maybe neither and just use css3 transforms?

The answer depends on your manipulation and animation.

If it's just translations, CSS wins for speed compared to canvas. I haven't tested, but I feel confident it easily beats SVG for the same sort of thing.

If you're going to be doing non-affine transformations or otherwise messing with the images (e.g. blurring them) you clearly want Canvas.

If you need event handlers per object, you clearly want a retained-mode drawing system like SVG or HTML+CSS. I haven't done enough CSS3 transforms to say how they compare in terms of speed to SVG, but they clearly do not have the robust transformation DOM of SVG.

This is a rather subjective question (or suite of questions) and you haven't yet given sufficient information for a clear answer to be possible.

Should I use CSS or SVG's for displaying shapes?

Use both.

CSS

Use CSS for basic shapes. Basic animations. Like you mentioned when you are using CSS to generate custom shapes all you are doing is adding borders of box shadows to create the illusion of the shapes you desire. Some may say this isn't future proof and could break on any update.

SVG

Use SVG for more complex shapes and animations. Depending on how you implement SVG you can do certain things. You can embed them directly or through an HTML img tag, you can even use javascript libraries to inject them into your application.

SVGs are able to be animated via manipulating the styles on the svg itself however this ( depending on what your goal is ) can become a very deep rabbit hole. My suggestion for SVG animation would be to use a javascript library.

My recommendation would be to use both. Get a feel for CSS first. To me it seems the route less obstructed and easiest to learn if you want things quickly. Also try SVG I have created some great effects using SVG libraries in the past, things that would have not been possible using CSS alone, they even work in IE9 ( not that it's supported any more ).

TLDR;

Use CSS for basic shapes and animations.

Use SVG for advanced shapes and animations.

HTML5 Canvas vs. SVG vs. div

The short answer:

SVG would be easier for you, since selection and moving it around is already built in. SVG objects are DOM objects, so they have "click" handlers, etc.

DIVs are okay but clunky and have awful performance loading at large numbers.

Canvas has the best performance hands-down, but you have to implement all concepts of managed state (object selection, etc) yourself, or use a library.

---

The long answer:

HTML5 Canvas is simply a drawing surface for a bit-map. You set up to draw (Say with a color and line thickness), draw that thing, and then the Canvas has no knowledge of that thing: It doesn't know where it is or what it is that you've just drawn, it's just pixels. If you want to draw rectangles and have them move around or be selectable then you have to code all of that from scratch, including the code to remember that you drew them.

SVG on the other hand must maintain references to each object that it renders. Every SVG/VML element you create is a real element in the DOM. By default this allows you to keep much better track of the elements you create and makes dealing with things like mouse events easier by default, but it slows down significantly when there are a large number of objects

Those SVG DOM references mean that some of the footwork of dealing with the things you draw is done for you. And SVG is faster when rendering really large objects, but slower when rendering many objects.

A game would probably be faster in Canvas. A huge map program would probably be faster in SVG. If you do want to use Canvas, I have some tutorials on getting movable objects up and running here.

Canvas would be better for faster things and heavy bitmap manipulation (like animation), but will take more code if you want lots of interactivity.

I've run a bunch of numbers on HTML DIV-made drawing versus Canvas-made drawing. I could make a huge post about the benefits of each, but I will give some of the relevant results of my tests to consider for your specific application:

I made Canvas and HTML DIV test pages, both had movable "nodes." Canvas nodes were objects I created and kept track of in Javascript. HTML nodes were movable Divs.

I added 100,000 nodes to each of my two tests. They performed quite differently:

The HTML test tab took forever to load (timed at slightly under 5 minutes, chrome asked to kill the page the first time). Chrome's task manager says that tab is taking up 168MB. It takes up 12-13% CPU time when I am looking at it, 0% when I am not looking.

The Canvas tab loaded in one second and takes up 30MB. It also takes up 13% of CPU time all of the time, regardless of whether or not one is looking at it. (2013 edit: They've mostly fixed that)

Dragging on the HTML page is smoother, which is expected by the design, since the current setup is to redraw EVERYTHING every 30 milliseconds in the Canvas test. There are plenty of optimizations to be had for Canvas for this. (canvas invalidation being the easiest, also clipping regions, selective redrawing, etc.. just depends on how much you feel like implementing)

There is no doubt you could get Canvas to be faster at object manipulation as the divs in that simple test, and of course far faster in the load time. Drawing/loading is faster in Canvas and has far more room for optimizations, too (ie, excluding things that are off-screen is very easy).

Conclusion:

• SVG is probably better for applications and apps with few items (less than 1000? Depends really)
• Canvas is better for thousands of objects and careful manipulation, but a lot more code (or a library) is needed to get it off the ground.
• HTML Divs are clunky and do not scale, making a circle is only possible with rounded corners, making complex shapes is possible but involves hundreds of tiny tiny pixel-wide divs. Madness ensues.

What is the difference between SVG and HTML5 Canvas?

See Wikipedia: http://en.wikipedia.org/wiki/Canvas_element

SVG is an earlier standard for drawing
shapes in browsers. However, SVG is at
a fundamentally higher level because
each drawn shape is remembered as an
object in a scene graph or DOM, which
is subsequently rendered to a bit map.
This means that if attributes of an
SVG object are changed, the browser
can automatically re-render the scene.

In the example above, once the
rectangle is drawn, the fact that it
was drawn is forgotten by the system.
If its position were to be changed,
the entire scene would need to be
redrawn, including any objects that
might have been covered by the
rectangle. But in the equivalent SVG
case, one could simply change the
position attributes of the rectangle
and the browser would determine how to
repaint it. It is also possible to
paint a canvas in layers and then
recreate specific layers.

SVG images are represented in XML, and
complex scenes can be created and
maintained with XML editing tools.

The SVG scene graph enables event
handlers to be associated with
objects, so a rectangle may respond to
an onClick event. To get the same
functionality with canvas, one must
manually match the coordinates of the
mouse click with the coordinates of
the drawn rectangle to determine
whether it was clicked.

Conceptually, canvas is a lower level
protocol upon which SVG might be
built.[citation needed] However, this
is not (normally) the case—they are
independent standards. The situation
is complicated because there are scene
graph libraries for Canvas, and SVG
has some bit map manipulation
functionality.

UPDATE:
I use SVG because of its markup language abilities - it can be processed by XSLT and can hold other markup in its nodes. Similarly I can hold SVG in my markup (chemistry). This allows me to manipulate SVG attributes (e.g. rendering) by combinations of markup. This may be possible in Canvas but I suspect that it's a lot harder.

---

Related Topics