Eddie Traversa is an author, Web consultant, and DHTML, and SVG guru. His book, “Dynamic XHTML Developers Guide” is a joint project he worked on with Jeff Rouyer of HTMLguru.com fame.
For those who are new to SVG, what is it?
In a sense, we are all new to SVG, so it’s important to understand what it is and how this will ultimately affect our web development/design practices. SVG is an acronym for Standard Vector Graphics. A simplistic but good way to think of SVG is to think of it as the HTML XHTML equivalent for Vector Graphics. It is an XML-based programming language that allows for the creation and manipulation of Vector Graphics.
The XML part is pivotal to SVG because it allows for the easy integration of other specifications such as SMIL and the DOM to name but a few. Vector-based graphics also have the advantage of being a lower weight than traditional graphics such as jpg, gifs and also do not degrade when scaled. Combine these advantages with the ability to manipulate every aspect of the image and/or text it makes for a very compelling and attractive medium for developers and designers to explore.
The interesting part from a psychological viewpoint is that artists will be programming and programmers will be creating “art.” SVG provides for the blending of two areas that were previously thought to be quite separate. Time will tell what effect this will have on our workflow and web page building practices.
How does it compare to Java? Flash?
SVG is most often compared to Flash because both work with Vector Graphics and both have motion and multimedia capabilities. There are some really important differences though. SVG is open source, meaning that you can right-click on the page and see the source code. That is an enormous benefit to developers and designers because many people like to get behind the scenes and learn by pulling someone else’s code apart.
A good way to think about this is that SVG can do everything Flash does and then some. Flash cannot do everything SVG does, at least not without a considerable amount of effort and trouble. For example, it is feasible to create an international language system in Flash, where the Flash page adapts to the user’s language. But doing so would require some extensive effort on the Flash developer’s behalf. In SVG it is simply a matter of adding a few tags to accommodate different languages.
SVG really is a feature-rich specification and that can’t be emphasized enough. But, it does currently fall behind Fash and Java in terms of popularity. Chances are if you create a flash page or have a java applet on your web pages that the user will be able to access your page without too much difficulty.
Since SVG is relatively new by comparison, chances are that the user will need to download a plug-in and the plug-in itself is quite large to download and is CPU intensive. That’s a significant advantage that Flash and Java both currently hold over SVG. But, the future looks brighter as browsers move towards supporting SVG outright and that means no plugin.
Much of the above also holds true for Java, but an important distinction here is that attempting to do many of the things that SVG is capable of with Java results in a much larger file size by comparison.
Other than the Adobe Plug-in, what other tools does you need to create SVG pages?
You will need a good HTML editor to write out the code. Other than that you don’t really need anything, but I find when creating complex graphics something like Jasc’s Web Pro is useful as it’s specifically designed for SVG. You can also create SVG in Adobe Illustrator, Ulead PhotoImpact 7, and quite a few other programs. Basically, any graphic program that allows for the creation of SVG is handy to construct complex vector images.
Some people may find it faster and easier to use PhotoShop to create graphics like those found in your tutorial examples at Webreference.
What advantages does SVG offer over graphic programs like PhotoShop and Freehand?
As mentioned above there are graphics programs around that will allow for the creation of SVG. It is also possible that programs like Photoshop will support SVG in the future given that the company has made a significant investment in SVG. I don’t see that the transition to creating the graphics for SVG will be that great a learning curve.
But creating graphics is only one part of SVG. SVG easily hooks into other technologies like SMIL and the DOM and this to me is really what separates SVG from traditional images like gifs or jpgs. We can manipulate an SVG image color, shape, texture, make it morph into something else, literally the possibilities are endless. In a paradoxical way, the advantage (more control over web pages) is offset with the disadvantage (lots to learn). In short, SVG isn’t perfect.
Because you have to indicate the exact points for the property such as:
(fill:rgb(39,44,231);)
What is the easiest way to determine the points?
I think it is more important to remember the general concepts of working with SVG than attempting to remember every point in a complex graphic and then remember the points that need to be animated. To help in this endeavor, I usually split the workflow into two separate domains; Creating and styling the images and manipulating the images.
Typically, I create and style the images in a graphics application, which removes much of the tedium of typing out numerous points. There may be some touch-up work involved, where diving into the code allows more finite control (knowing what the code means is important here), but the general flavor of the image is handled by a graphics application.
Dynamically manipulating the image I prefer to hand-code in because very often I need very precise control. What helps me personally in determining the points to manipulate and how to manipulate them is my experience with DHTML and Flash.
If you know how to dynamically position a CSS layer or manipulate some of its properties, then the jump to SVG is not as great as many would believe. Similarly, if you have experience in Flash then you already have experience in manipulating Vector Graphics, particularly if you use Action Script to do so. In short, if you have some experience with HTML, CSS, JavaScript, Flash then these stand you in good stead to handle SVG.
There is even a way to work with SVG for those that prefer to work in an application. For example, Jasc’s Web Draw allows you to dynamically manipulate SVG through the use of a timeline. Adobe GoLive also includes SVG support so there are now quite a few software programs beginning to appear with the SVG developer in mind. The problem with using packages like this is you are always bound by the capabilities of the programs, whereas by comparison the only thing binding you is the specification itself and your imagination.
What other resources do you recommend for people who want to learn more about SVG?
I am really fond of the material at the Adobe SVG center, that’s a good starting point as it links out to other SVG resources. Then, of course, there is always the Holy Grail of SVG; W3C.
Congratulations on your book project on dynamic XHTML. What can you tell us about it?
“Dynamic XHTML Developers Guide” is a joint book project by Jeff Rouyer of HTMLguru.com fame and me. The primary focus of the book is to lead the reader through the process of building a state-of-the-art Dynamic XHTML site.
One of our goals for this book was to inject as much of our personalities and humor into the book as possible, without distracting the reader from the actual content. To achieve this, we created some characters, eg, Herbert the Sock Monkey and Lenny the Lizard, among others, and they are used as guides throughout the book and the templates to help illustrate concepts in an amusing way. We think it’s going to be an informative and fun book to read.
As readers read through the book they will be introduced to “Smart Web Page Technology” where the page ‘magically’ transforms to user-defined preferences. There are quite a number of Dynamic XHTML techniques throughout the book, ranging from building different menu systems to graphical techniques used in the making of the templates, to some really neat Dynamic XHTML text effects, that originally were based on C++ and advanced geometry.
While the above may sound complex to some, Jeff and I have gone to some lengths to make both the novice and the expert feel at home. That’s really been the tricky part of writing this book.
How is it different from other books on XHTML?
Most of the books I have seen/read on XHTML focus on the XHTML specifications and therefore tend to be reference-oriented. Reference type books are valuable additions to the XHTML paradigm, but they don’t lead a user through the process of building a complete XHTML website from the ground up. Dynamic XHTML Developers Guide addresses this issue by deconstructing a Web Template.
It also differs from other XHTML books, in that it presents new concepts to the Web Development / Design Community. Both Jeff and I like to think of ourselves as “pseudo inventors” so the book reflects our latest thinking on the state-of-the-art Dynamic XHTML techniques.
What do you think we can expect to see in the next few years?
I think the next few years will mark an important development phase that is likely to define the Web for years to come. For example, will Flash die off, will be XML become the language of choice, will Netscape ever make a comeback? It will be exciting to be involved in this era, but at the same time, a little daunting as the changes may be quite rapid.
I think the developers and designers who keep pace with these changes will most likely be the ones that not only survive but also thrive.