Student name: Peter Paleologopoulos
LOGIN: ppaleo01

Tufts COMP 150-IDS (Spring 2015):
Internet-scale Distributed Systems

Tufts COMP 150-IDS Final Project
SVG vs. HTML5 Canvas


As the World Wide Web has evolved, so too have the tools used to publish and express information. This is especially true for HTML, which has always been integral to the publication of Web pages, so any changes or revisions to the HTML specification have always been a point of contention. One such point of contention has been which tools HTML5 should support for drawing graphics. Two choices have become the most commonly used for this purpose: SVG and the relatively new canvas.

The W3Schools wiki describes SVG as “a set of instructions on how to create [an] image.”1 As opposed to a rasterized image, which is made of pixels of specific positions and colors, SVG produces a vectorized image, which is created from the aforementioned instructions. Canvas is a similar tool which was released by Apple in 2004 and was integrated into HTML5 as a native way of creating vector images using scripts. As stated by the Web Hypertext Application Technology Working Group2 and W3C, web pages can use both canvas and SVG somewhat interchangeably based on their respective strengths and weaknesses.


According to the W3C Wiki, one of the biggest benefits to using canvas over SVG is that it’s more memory- and time-efficient to use. However, because canvas creates a new graphic every time the page is loaded before converting it to a pixel format, it cannot be freely resized without reloading the page or causing distortion due to the enlarging of pixels. The WHATWG wiki summarizes the distinction between the two formats by stating that they provide different functions—SVG graphics are retained mode (they do not need to be re-generated), whereas canvas graphics are immediate mode (they are re-generated every time the element is loaded.) SVG is also declarative, unlike canvas, so it can be edited using programs such as Inkscape straight from a webpage.

This is an important distinction—it may be preferable for all of a page’s content to be editable to increase the power of HTML pages, but it can also have unintended consequences. Metcalfe’s Law states that larger systems tend to be more powerful than smaller unconnected systems, and this concept can be extended to the process of saving and being able to easily edit content from the web. The easier it is for a user to interact with content that they come across, the more powerful a system the web becomes. SVG can also store non-visual information in its vector graphics, which is important for non-visual accessibility to the Web and for data crawling in Web pages. A similar capability of SVG’s is its ability to accommodate mixed content such as XHTML.

One principle that canvas may cause issues with regard to, as opposed to SVG, is the Rule of Least Power. The rule states that when there is more than one language available for use on the Web, the language which is the simplest (and thus the easiest to use when it comes to accessibility, for instance) should be used. However, this rule should not be used indiscriminately—if a language provides capabilities that any number of simpler languages cannot, then perhaps it might be necessary to make use of it.

This is a small sample of the distinctions between SVG and canvas, but in the simplest terms, canvas provides for a faster, more memory-efficient system of creating vector elements, whereas SVG is more extensible and, it could be argued, is healthier for the continued growth of the World Wide Web. However, the WHATWG wiki recommends the use of both canvas and SVG in Web pages, and HTML5 has supported both formats since canvas’s release in HTML.


Since Apple’s submission of the canvas tag to WHATWG in 2004, curators of Web content have argued over the best use of the element type and whether it’s even necessary or useful to have for use in HTML. One of the first messages on the WHATWG mailing list by Dave Hyatt of Apple notes that canvas elements can make use of CSS styling such as colors.3 As one of the original engineers working on Safari at Apple, Hyatt wished to introduce the canvas element into consideration for the then-nascent HTML5 protocol. Not all posters were so open to this idea, though—a post from the 20th of April, 2005 by Olav Junker Kjær makes several arguments in favor of retaining use of SVG over canvas. Kjær argues that SVG and canvas overlap too much for the introduction of canvas to be useful or necessary, and further argues that because of concerns that browser vendors will have to implement the element themselves, companies such as Microsoft will simply not support it at all. Kjær’s argument follows Metcalfe’s Law as well—if only certain clients can make use of an element, the element will not retain the power of elements that anyone can use, such as SVG.

Others on the WHATWG board assented. One Dean Jackson expressed concerns that canvas is simply a container for JavaScript, and echoed the sentiment that use of the element could lead to issues of accessibility. Still, board list members continued to debate the possibility of changing the spec for canvas to assuage these fears in the hopes of accommodating Apple’s request. In the thread “Text support in canvas”, a contributor named Jayant Sai called canvas a “GREAT start” for client-side graphics and encouraged support for the possibility of text rendering in canvas, although others asserted that this could lead to further issues of accessibility. Not all users were so excited at the possibility. A thread entitled “canvas elements etc,” some users were apprehensive at the introduction of the element; many pointed out its similarities to SVG and responded skeptically to the need for a new element of this type.

Although there were good reasons to argue against the adoption of canvas as an option, the real issue with a lukewarm response to the element type was not the technical reasoning behind why not to adopt it but that there was a negative response at all. If Web content creators and curators alike had no interest in the use of canvas, this response combined with the onus of implementation being on browser vendors meant that the Web community at large might simply fail to make use of the specification. One of the developers of the browser Opera, Anne van Kesteren, posted a thread on October 25th 2007 stating his interest in extending canvas with the help of elements from SVG. No developers responded.

Present Use

Despite what appears to be developers’ reticence towards use of the canvas element, it is presently supported by the HTML5 specification. As the original creator and submitter of canvas, Apple has made use of it in its own proprietary software, as was originally intended. The Apple Safari Developer Library has several entries on use of canvas for the creation of Web graphics4, and notes that it is easy to modify elements of this type using CSS: “give it a border or a background, round the corners, move it around on the screen, hide it offscreen, and so on.”

In a post to the WHATWG mailing list on April 10th, 2008, the specification editor Ian “Hixie” Hickson expressed optimism about adoption of the canvas tag. Hickson stated that the tag was “popular with vendors” despite claims by another user in 2006 that the HTML5 specification was not being selective about which parts it adopted based on popular use. Hickson also compiled a list of responses in a thread entitled “[whatwg] Canvas feedback (various threads)” in 2011 which seemed to indicate that interest in canvas had not tapered off. The nature of the debate, which seemed to be whether to use an entrenched format (SVG) over an untested newcomer, had shifted to a discussion on how to adapt canvas so that it would fill a formerly-nonexistent niche. One Charles Pritchard states in a thread entitled “[whatwg] Using SVG instead of Canvas for extensions” that developers should integrate SVG images into their canvas elements to make the best use of vectorized images.

Posts pertaining to canvas on the WHATWG board continue to the present day. Most of these posts pertain to suggested changes to or issues with the spec, but this is in line with the nature of the board. A blog post on the Sitepoint website, intended to teach the use of HTML, CSS, and related technologies, states that the canvas element “is used everywhere” for games and demonstrations. The author recommends the use of SVG for many purposes that developers use canvas for,5 and predicts that SVG will continue to grow as a tool, while warning that canvas’s nature “will always impose limitations.”

Meanwhile, other uses for canvas have appeared on the Web. In his “Canvas Cycle” series of animations, artist Mark Ferrari and developer Joseph Huckaby use the element to cycle through color palettes for Ferrari’s animated pixel works.6 Other artistic and graphical experiments have used canvas in new and interesting ways that SVG could not do as easily or efficiently.


I don’t know that I have enough experience with Web development or standards to have an educated opinion on the use of canvas versus SVG. From my research I have seen that there are benefits to using both formats and that there are works that can only be done in one or the other. I have concerns about canvas’s lack of support for both accessibility ad mixed content (not to mention seeming to violate KISS and the Rule of Least power, for these same reasons) but I am confident that the Web community will continue to work to make it suitable for use, especially with the knowledge that it is a powerful tool that allows for greater results than could be achieved with only SVG.

I am also confident that there has been a change in reception from what initially appeared to be a heavy preference on the Web for SVG. Although many on the WHATWG list may remain unconvinced, many artists and developers seem to have welcomed the possibilities that canvas offers with open arms. Any of my concerns about Metcalfe’s Law and of redundancy have been somewhat assuaged by my research—I might even venture to say that if canvas were improved enough, SVG might fall by the wayside. Only time will tell on that front, of course.

One parting concern I would like to conclude this report with is that of security. The HTML5 specification has only been in effect for approximately a year at the time of writing this report, and has not yet been thoroughly tested for security via popular exposure. A user on the Stack Exchange division for the browser Tor explains that the canvas element can be used to “fingerprint” users, which could be helpful for phishing scams and other illicit activities.7 Other issues may come to the forefront in the future, and members of the Web community should continue to be mindful of the tools they use in their own projects as well as ones they are collaborating on. Still, as of now the future remains bright for HTML5, which will hopefully continue to grow.

Works Cited

1 "SVG FAQ." SVG. W3Schools, 6 May 2008. Web. 26 Apr. 2015. "".

2 "SVG and Canvas." WHATWG Wiki. Web Hypertext Application Technology Working Group, 30 Nov. 2007. Web. 26 Apr. 2015. "".

3 Hyatt, Dave. "[whatwg] Re: Canvas Tag." From Dave Hyatt on 2004-07-13. N.p., 13 July 2004. Web. 27 Apr. 2015. "".

4 "Safari HTML5 Canvas Guide." About Canvas. Apple, 18 Sept. 2013. Web. 27 Apr. 2015. "".

5 Buckler, Craig. "7 Reasons to Consider SVGs Instead of Canvas." Sitepoint. N.p., 18 Apr. 2012. Web. 27 Apr. 2015. "".

6 Ferrari, Mark. "Canvas Cycle." Effect Games. N.p., n.d. Web. 27 Apr. 2015. "".

7 "HTML5 Canvas Security Flaw." Tor Stack Exchange. Stack Exchange, 8 June 2014. Web. 27 Apr. 2015. "".