Web DevCenter
oreilly.comSafari Books Online.Conferences.
MySQL Conference and Expo April 14-17, 2008, Santa Clara, CA

Sponsored Developer Resources

Web Columns
Adobe GoLive
Essential JavaScript

Web Topics
All Articles
Scripting Languages

Atom 1.0 Feed RSS 1.0 Feed RSS 2.0 Feed

Learning Lab

SVG On the Rise
Pages: 1, 2

XML-powered graphics make sense

By now everyone knows that XML can solve all the world's problems! Seriously, using XML to mark up graphics is just as much of a benefit as using it to mark up textual data. It's about semantics; a graphic, or the pieces within that graphic, can have as much semantic meaning as any other document.

Of course, marking the image up as a collection of graphical primitives (e.g. circle, line, rectangle) might not always add much, but it does add something. Structure with semantics helps accessibility, and as XML is the dominant structured format on the Web at the moment, you get a whole bunch of tools that can work with that structure for free.

Then, as SVG is XML, you have the option of easily adding much more semantic meaning. You can describe parts of the image using RDF, or any other XML metadata format. You can include XHTML descriptions for each part.

You can also add data in your own custom namespace to describe whatever you want, whether it's more metadata, details on how to return from the graphic to the original representation of the data, or data that can be used to transform one graphic into another. It's not "the end of the road" for the image, as Jacek put it. XML is good for graphics, because it helps ensure that rich content is not lost to the user. It's about not losing data to a proprietary black box; it's about information you can truly reuse and recycle.

So by using XML syntax, SVG graphics are always structured and can have more embedded semantics, which is a very good thing. And it's not just financial data, medical records, and the like that can benefit from the structure XML provides. Graphics such as maps, logos, user interfaces, animations and illustrations are all improved by structure and semantics.

With XML you also get integration -- now. You have the huge range of server-side XML tools to work with, as well as the fact that using XML for graphics fits into the current model of XML workflows. This way, you leverage all the other XML technologies and interoperate with them, including standards such as DOM and XSLT, and tools with XML libraries such as JSP, ASP, and PHP.

The power of this integration can be demonstrated with the simple example of a custom graphic such as a business card or post card. A developer can create an SVG template for the graphic and use server-side tools such as transformations to customize it to the end user's needs. Nearly every modern programming language has support for XML. If your data is in XML and your tool set works with XML, it makes sense that your graphical representation is XML.

SVG already has a uniform platform

Jacek said there is an advantage to having a uniform platform. SVG has one -- it's called the SVG specification. There are lots of SVG implementations, including viewers, editors, and server-side tools for content generation. All these implementations must conform to the specification, mostly because if they don't, developers will use an implementation that does conform.

Developers are tired of having to check an implementation's documentation to see how it diverges from the specification, and the SVG implementors have noticed this. Furthermore, we have a fully conformant SVG viewer in Apache Batik, which is available under an open-source license. Having such a freely available and complete open-source solution available helps the platform: it keeps the closed-source implementations honest, it gives them something to compare to (and even examine the source if their licensing terms allow), and it gives the developers ammunition for guaranteeing the uniform platform.

So I agree with Jacek, a uniform platform is a good thing to have, and I am glad we started with one in SVG.

SVG files are bandwidth-friendly

Jacek calls SVG a bandwidth hog. I disagree, and for two reasons. Firstly, in many cases the declarative animation syntax used by SVG (e.g., move this shape from point A to point B, over 10 seconds, while fading from blue to red) is much more efficient than a frame-based approach (drawing multiple frames, each with the shape in a slightly different location with a slightly different color -- i.e., many static images shown one after the other).

This size advantage becomes more obvious the longer the animation. Of course, the size difference between the declarative and frame-based approach is also very dependent on the animation itself, but SVG animations make effective use of bandwidth. Again, I point to Antoine's excellent Sacré SVG! column for an example of an interactive SVG animation being smaller than the SWF equivalent, and that is for a very small animation.

Secondly, it is worth noting that the SVG Working Group specifically decided to use gzip compression as it does a fantastic job of compressing SVG files. We put our trust in compression experts! Every SVG viewer is required to support gzip-compressed SVG files. Not only that, gzip compression is included in many system libraries, meaning that it is not adding to implementation footprint. The size of SVG files was a major concern to the Working Group and we think we addressed it. I hope the misconception that SVG files are over-verbose does not stick.

The mobile community has chosen SVG

About the time SVG became a W3C Recommendation, the Mobile Device community adopted SVG. Mobile industry companies such as Nokia, Ericsson, and Openwave joined the SVG Working Group. They needed a format for vector graphics on third-generation mobile phones. They wanted it to be an open, XML-based, modularized, profilable technology that would fit into their architectural plan, which included XHTML Basic, CSS, and SMIL. They chose SVG and you can see the results of the work in the Mobile SVG Profiles.

The mobile standards body 3GPP is defining the platform for the next generation of mobile phones in Europe and the U.S. They have chosen SVG Tiny as a required format for Multimedia Messaging (SVG Basic is recommended). I've already seen implementations of SVG on current generation U.S. mobile phones (even with a 75x25 black and white display), as well as Palm Pilots, PocketPC devices, other PDAs, electronic books, Japanese mobile phones (Sharp sells an SVG-capable phone in Japan), and in-car navigation systems.

I was once concerned that the completeness of SVG would lead to too much of a burden on implementors. I don't have that concern anymore, now that I've seen many interoperable implementations, from many vendors, on many devices. The recent modularization and profiling of SVG into SVG Basic and SVG Tiny can only help future implementors.

Why SVG fits into the Web

As this is a web development forum, I think it is important to outline how SVG fits into the overall architecture of the Web. Let's have a closer look:

  • XML syntax: I don't think there is a need to go over the benefits of being an XML document, although there are a few new points worth mentioning. As an XML syntax, SVG can be integrated with other XML documents, such as embedding SVG inline within an XHTML file, or combining SVG with MathML to create a graphical representation of a mathematical formula. Antoine's recent article shows how to extend SVG to support XForms, the replacement technology for HTML forms.

  • Web Services: SVG is the perfect fit for graphics in Web Services. This is about integration and interoperability with other XML technologies. Being XML, SVG diagrams or animations can be easily encapsulated in a SOAP message. Also, the interactivity and programmability of SVG means it can be used to build more complex graphical user interfaces to Web Services.

  • Stylability with CSS: SVG is stylable, using CSS in the same manner as HTML. You have style attributes, selectors such as "class", internal style sheets, referenced style sheets, and user style sheets. You may already know the mantra: separate structure/content from presentation. You also know the benefits to accessibility of this approach. This was built into SVG from the start.

  • Animation with SMIL: SVG uses the SMIL animation syntax. This is useful in a standalone SVG file, but also enables SVG documents to be embedded in a multimedia SMIL presentation, allowing the audio and video components to have overlaid vector graphic animations.

  • Scripting: SVG can be scripted with any language (e.g. Perl, Python, and even Java), but SVG user agents that support scripting must at least support full ECMAScript (i.e. JavaScript). Every element, property, and attribute within the SVG document can be modified. Not only that, you can create any SVG element and insert it into the document for rendering. The millions of programmers familiar with JavaScript can make an easy transition to the powerful scripting support in SVG.

  • The DOM: Being XML, SVG has the complete XML DOM, including DOM Core and DOM Events. This means developers do not have to learn another programming interface to work with SVG, and they'll immediately find that the familiar DOM interfaces give complete control over the graphics within the SVG document. SVG also has its own extended DOM which provides a very complete graphical model for programmers, including convenience functions for common operations, such as matrix multiplication.

  • Everything else: Standards such as JPEG and PNG for raster images, transformation to and from SVG using XSLT, animation using SMIL, color management using ICC color profiles, and international text with Unicode. All built upon the well-proven and industry-accepted graphical principles used in Postscript, PDF, Java2D, and Mac OS X Quartz.

As you can see, SVG was designed to be an important component in the established and open Web architecture. Adopting open, truly standards-based solutions ensures that the pieces fit together in powerful, extensible, and economical ways. SVG, along with XHTML and CSS, will be part of the two-dimensional rendering engine of the Web.

Final thoughts (or </article> <svg>)

SVG was not designed to replace any existing technology; it was designed to be the best solution for vector graphics on the Web. By producing SVG with regular public review, requirements for implementation experience of its features, and having the participation of organizations and companies leading the development of -- and sometimes competing with each other on -- graphics technologies, you could have bet on the positive outcome. I think SVG's time has already come.

SWF is an extremely popular, proprietary format that has been around for years, with an extremely popular authoring tool. SVG is a new, open XML format, generally acknowledged to be technically superior, which has not yet reached the same level of popularity. But with the enthusiasm shown by the people currently developing SVG content and the strong support from industry and Open Source developers, it shouldn't be long before SVG has the authoring tools and market share to be a dominant Web format.

Dean Jackson is a member of the SVG Working Group.

Return to the Web Development DevCenter.