• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL



The release of the SVG 1.0 specification as a full W3C Recommendation was proof of the enabling effect of a strong, active, and vocal user and developer community. Less visibly to the public, it was also a demonstration of the W3C process that enables competing companies to come together in a vendor-neutral space and work on commonly agreed, open specifications for the benefit of the Web in general and to grow the market.

SVG was the first specification to not only have a test suite, but also to publish the results of testing on named implementations. During the Candidate Recommendation phase, implementers and content creators gave a large amount of valuable feedback that helped to improve the clarity and technical accuracy of the specification. As a result, compared to other specifications at an equivalent level of maturity, SVG was extremely well implemented by the time it became a W3C Recommendation on September 4, 2001.

That event was also, for me, a personal triumph and the culmination of a long journey. Graphics was the reason I first became involved with Web development, in 1993. When I attended the first-ever Web conference at CERN, Geneva, in May 1994, I was working for a computer graphics facility and was involved with the emerging PNG specification and the IETF HTML Working Group that produced HTML 2.0. In December 1995, I presented a paper on future development challenges for Web graphics at the fourth Web conference in Boston, was hired by W3C to head up the graphics area, and published (in 1996) a requirements document for scalable graphics.

At times, it seemed that the world was not ready for vector graphics on the Web; it took a lot of work raising awareness and gathering support before finally, in September 1998, the first SVG Working Group was formed. Then, suddenly, we were off and running. There was a flurry of ideas and discussions. Graphics experts from many leading companies were enjoying the experience of freely sharing ideas and wished to create a new format that did what, we all felt, graphics should have been doing all along! The first working draft was released in February 1999 and the second in April of that year. By May, there were already three implementations (from IBM, BlackDirt, and Adobe). And this pace continued throughout the development of SVG 1.0.

I have been asked how the world would be different if a vector graphics standard had been available early on. The answer is that certainly it would have been better to have something sooner, but that we would also have a legacy problem and have to reinvent something like SVG anyhow. Early in the development of the Web, XML did not exist. Vector graphics might have been an HTML extension, or a binary format, but would not have had the benefits that XML has brought. Style sheets were not available, so it would have been unstyled. The XML DOM was not available, so scripting and dynamic content generation would have been specific to the format and not shared tools and techniques with other content. The Web Accessibility Initiative had not started, the Unicode standard was not yet accepted by the industry, and the general state of software internationalization was immature; so an early graphics standard would not have been universally accessible. In a sense, it was possible to create SVG only after the shared infrastructure on which it is built had been developed.

So, SVG was developed when its time had come, and is now successful. There are many implementations of viewers and content creation tools. The ease of generating and modifying SVG, using visual tools or simple text editors, has been a boon for content developers and has clearly boosted adoption. The ready integration into existing XML-based workflows has meant that SVG rapidly found a place in information delivery—representing graphics, not text—but in terms of processing, just another XML component.

That one crucial difference from other XML languages—that it produces a rendered result—has made it a natural target for XML transformations using XSLT or generation with programming and scripting languages. Regardless of what the origin XML language is representing—weather data, geographical information, chemical molecules—transforming it to SVG allows this specialized, domain-specific markup to be given a visual form that can be understood and interacted with. You will meet many examples of this process in the course of the book. Unlike with some “write once” binary formats, it is common and expected that SVG graphics will be revised, rewritten, or include components that change over time.

Programmers have been generating graphics programmatically for some time, but while the resulting graphics were standard—one of a handful of raster formats widely used on the Web—the programming interface and underlying model varied widely and were specific to the particular graphics toolkit used. Programmers were unable to share skills or transfer experience from one project to the next. SVG changes all that. Not only is the output graphic standard, but the programming interface and underlying model are also standard. You can build experience over several projects, discuss experiences with colleagues, and apply lessons and techniques from one project to the next one. In the course of this book, you will see many approaches to creating graphics programmatically, but they are all variations on a theme. They all rely on the underlying model of SVG in terms of vector graphics objects and the Document Object Model. The SVG rendering model and syntax are presented in the first part of this book; you can read through it or refer to it as you study the programming examples in subsequent parts. Thus, your understanding builds as you work through the material. Be sure to read parts that use programming languages you are not familiar with, too.

Many graphics represent text, and here a key difference from other graphics formats emerges. In SVG, the graphic text to be displayed is stored in the SVG file as a Unicode text string. It doesn't matter if the text is in an unusual font, stretched, skewed, placed on a spiral, or filtered—it is still selectable text. It may be directly edited, generated on the fly by the server, or created in response to user interaction on the client. Unlike special “alternate text” added as an afterthought to provide some measure of accessibility, the text in SVG is real text. It will not become out of date or out of sync with the graphic presentation; it is the graphic presentation. This is an enormous benefit in terms of accessibility for the disabled community; screen readers and text-to-speech or Braille generators can access this structured text and allow the visually disabled to navigate through the graphic content.

As is often the case, an accessibility advantage gives benefits to the nondisabled community as well. By using live text, SVG can be searched and indexed, both by users and by search engines. When you're interacting with an SVG graphic, you can look for specific text strings, to copy and paste them into other applications. Text in SVG is also well internationalized. Text in any of the world's languages can be used and is still searchable and selectable. In today's multilingual society, this capability provides a significant advantage. It is no longer sufficient to assume that people in Europe or the Americas need simple, “single-byte” languages, that the Middle East needs only bidirectional languages, that the Far East is the only place that needs “double-byte” languages, and that we treat any other combination as an insignificant minority. Instead, the reality is that there is a single, cosmopolitan, global market. SVG reflects that realization.

Another change in the market is the rise of handheld devices—personal digital assistants, Pocket PCs, PalmOS devices, mobile phones—and other nontraditional devices such as game consoles, set-top boxes, and information kiosks. Bringing challenges due to lower CPU power and memory, these devices also have a refreshing lack of legacy problems and are often the first to adopt new W3C specifications such as XHTML, SMIL, and SVG. Their use is widespread and growing; not only are mobile devices easier to carry—in a pocket, not a backpack—but they are also more affordable to a larger segment of the population. Over time, the number of people accessing the Web using such devices is likely to greatly exceed the number using traditional desktop or laptop computers. It is vitally important, to avoid fragmentation of the information space, that the same specifications—URLs, HTTP, and content formats including SVG—are used in the mobile Web as well as the “desktop Web.”

Recognizing this fact, work on SVG has not stopped at W3C. Indeed, SVG 1.1 and SVG Mobile moved to Candidate Recommendation on April 30, 2002, and work on SVG 1.2 has started. Rest assured, though, that SVG 1.1 has the same features and syntax as SVG 1.0; the specification of those features is expressed differently to allow subsetting. SVG Tiny and SVG Basic, collectively called SVG Mobile, are interoperable subsets of SVG 1.1 specifically designed for mobile devices. You can read more about the future of SVG in Chapter 27. For now, it is sufficient to know that by reading this book about SVG 1.0, you are making the best possible preparation for also doing work on SVG Mobile.

Welcome to the future.

>Chris Lilley W3C Graphics Activity Lead and SVG Working Group Chair

  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint