SVG: An Image Description Language for the Web

In the early days of the Web, most browsers allowed exactly two formats for embedded images: The lossless Graphics Interchange Format (GIF), which was a good choice for logos, diagrams, and primitive animation loops, and the lossy compressed Joint Photographic Experts Group (JPEG) format, which is better suited for photos. Dissatisfaction with technical limitations and patent issues surrounding GIF led to the development of the replacement Portable Network Graphics (PNG) format, which offered more colors and partial transparency at a reasonable lossless compression rate. PNG is a great format, so it took “only” about a decade to become widely supported by all the different browsers. This gives us three standard image formats to choose from (standard in the sense of not requiring a plugin on any of the mainstream browsers), but all of them only support raster graphics.

What about vector graphics? Raster graphics are fine if viewed at a fixed resolution, but they suffer significant quality loss when resized, for example while preparing a high quality printout. Vector graphics are by design immune to resizing artifacts. They may also lead to smaller file sizes and offer additional functionality, such as complex animations and scripting capabilities. A common vector format that exemplifies these possibilities is Flash. But unfortunately, Flash is a proprietary format, relying on proprietary browser plugins and authoring tools, which may not be supported on all platforms. For example, at the time of writing, iOS systems still lack any Flash player, and it appears unlikely that this might change in the foreseeable future.

Does the Web need to rely on some proprietary format for vector graphics? No. There is actually a very well suited open format available: Already back in 2001, at the height of the XML hype, the W3C published the XML based Scalable Vector Graphics (SVG) format. An SVG image is composed of vector shapes (lines, curves, polygons, etc.) expressed as XML elements, which are drawn by the browser independent of the display’s resolution. Upon loading, the SVG elements become part of a Web page’s DOM. This means, that these elements and their corresponding vector shapes can be manipulated through JavaScript, or used as sources for JavaScript events, thus allowing the programming of arbitrarily complex user interactions. Simple animations can be described directly in the format, while more complex animations may be programmed though JavaScript. Possibly the best way to learn about SVG is to start experimenting with the guidance of an online tutorial. Two very good tutorial series can be found at carto:net and Learn SVG.

Until recently, there was one major problem with SVG: Similar to the development of PNG, we “just” had to wait for about a decade until all major browsers started providing decent, native SVG support. With Internet Explorer 9 finally jumping onto the bandwagon earlier this year, that wait seems to be finally over. With client software finally supporting SVG, are all hurdles to its adoption taken? Not quite yet: Server software still needs better out-of-the-box SVG support. For example, WordPress, the software used to power this blog, seems to do everything to block one from including SVG images inside a post. Not only is it hard to link to an uploaded SVG image without a special plugin, but by default WordPress will block the uploading of SVG files, considering SVG an unsafe file type. It appears, that this is not pure oversight, but a rational decision based on the fact, that SVG might be a little too powerful to be trusted. Being a very flexible XML based format, SVG allows the inclusion of JavaScript code. While this enables some of SVG’s unique features, it also opens the door to potential misuse: A site that allows users to post unfiltered SVG files may suffer the same cross-site scripting vulnerabilities as a site that allows unfiltered HTML uploads.

When I started to write this post, I planned to embed an SVG sample. But with the upload restrictions in WordPress, this turned out to be such a hassle, that for now I decided to leave this blog “image-less” for a little longer. Nevertheless, SVG is a promising, powerful Image Description Language for the Web. It has been around for quite a while now, but just recently gained decent out-of-the-box support by all of the latest mainstream browsers. Many Web sites already use SVG, but usually only in conjunction with some fallback mechanism, such as displaying a PNG image if SVG is not supported. Unfortunately, there are still some non-browser related stumbling blocks, such as limited support by server-side software, which are holding SVG back. Once these last problems are solved, I believe that SVG might have a very bright future. Some day it might even have become similarly widespread as the raster image formats GIF, JPEG, and PNG are today.

Before finishing this post, I should briefly mention one other promising new Web graphics technology: The new Canvas tag in HTML5 provides an empty raster based drawing surface, which can be easily manipulated though JavaScript drawing methods. I do not think, that the Canvas tag will be a direct competitor to SVG. The two technologies rather complement each other, just as raster and vector based image formats complement each other. Mihai Sucan has written a nice comparison between SVG and Canvas, which leads to this same conclusion. I could go on to write more about the Canvas tag, but that is a topic for another post.

This entry was posted in ITE 221, Web. Bookmark the permalink.