html5 canvas element and svg

Question

Why do we need the html5 canvas element, when the same can be achieved through embedded svg?

Answer 1

SVG and canvas aren't really interchangeable technologies. SVG is a type of retained mode graphics where everything is drawn from a rather abstract model (the SVG document). Canvas on the other hand is a kind of immediate mode graphics, where there is no model and the client (JavaScript) must take care of redrawing, animations etc.

Answer 2

SVG is a markup language for vector graphics and has DOM. This makes it very easy to alter the content after its creation.

Canvas is a painting surface just like MS Paint without an undo button. You cannot alter the content. You only can overpaint it. It is very performant because the browser does not need to handle a complete DOM for the image. And there is a possibility that canvas can handle 3D drawing in the future.

Answer 3

http://people.mozilla.com/~vladimir/xtech2006/ has nice comparison.

With canvas you don't have to deal with the DOM, which leads to faster and easier to write code. SVG is a mess as a specification, too...

Answer 4

an illustration: My blog engine (blogger) doesn't support SVG (it's not a XHTML document). I wrote a tool converting SVG to the canvas element: http://plindenbaum.blogspot.com/2009/11/tool-converting-svg-to-canvas_22.html

Answer 5

Here is an explanation of how to parse a simple svg and draw it on a canvas..

http://www.ikeralbeniz.net/2010/11/03/jugando-con-html5-canvas-y-svg-i/ http://www.ikeralbeniz.net/2010/11/04/jugando-con-html5-canvas-y-svg-ii/

in further posts the svg parser will be completed with transparencies and gradients

Answer 6

you might also find this comparison useful: http://dev.opera.com/articles/view/svg-or-canvas-choosing-between-the-two/

Answer 7

Because we then do not need to worry about what support such embedding ;-)

In this fashion the focus for application developpers is to adhere to standards and let the client designers do the same. and hence spare everyone to worry about plug-ins, versions, security setups, etc...

Answer 8

This isn't really a technical answer but I think it's the correct answer.

The bottom line is we don't need both. Yes I know there are differences between vector and raster graphics and different ways to control paths, objects, animations, etc. between the two, but to the end-user it's all the same. Yes, SVG is a little more powerful right now because of its longer existence but with a little more work you can do the same things with Canvas.

I believe the reality is Canvas is part of an overwhelming backlash against XML itself in web development. I believe most web developers, especially those working with limited time and resources, outside "enterprise" environments, dislike the complexity of XML. Canvas is part of a set of preferred just-do-one-thing technologies just like HTML5 is preferred over XHTML, JSON is preferred over XML, and even YAML is preferred over XML.

I think the idea is similar to the *nix philosophy of having many specific tools doing one thing right and efficiently rather than one mega tool doing many things. (It's also similar to the philosophy held by many fixed gear bicycle riders who shun incredibly precise and advanced derailleur technology for the simplicity of one direct drive gear.)

Don't get me wrong, I believe XML is an incredibly powerful and brilliant technology thought up and developed by brilliant people to be the ultimate Swiss army-knife of the web, programming, configuration, data storage, etc; but that doesn't mean it's easier to manage and style a series of complex paths than it is to just draw pixels on a .

I know my answer is opinionated and I don't intend this to be a flame. I love SVG and I wish it would have gotten more support over the years (especially from IE), but I feel the tide turning towards Canvas simply due to the psychology of standards setters and the web developers that influence them.

Long term I'd like to see SVG make XML optional and move to a more JSON-like structure that's simpler to manipulate with JavaScript, perhaps even becoming a vector-based Canvas context. That would be the best solution for the web in my opinion.