Programmer Musings

SVG Lives: the Summary

This is the last in a series of posts refuting some recurring claims about the death of SVG, In the first post, I gave a brief overview of SVG. In the subsequent posts, I refuted each of the major claims that I have seen for the death of SVG.

Those claims were:

1. Death by lack of GUI Widget Claim
2. Death by lack of the 3D Graphics Claim
3. Death by lack of the Video or Audio Playback Claim
4. Death bby lack of the Internet Explorer support Claim

I hope by now you can seem that these recurring myths are based mostly on misunderstanding or misinformation. SVG is a very effective technology, but it is not designed to do everything. Its popularity and usefulness have been growing for almost a decade now. Despite regular doom-sayers proclaiming the death of SVG, it lives on and grows stronger every year.

If you are interested in learning more about SVG, you should check out the following resources:

• Planet SVG from the SVG Interest Group
• The SVG Wiki
• Scalable Vector Graphics (SVG) at the World Wide Web Consortium site: the definitive reference
• State of the Art: An SVG Primer for Today's Browsers (It's long but it contains both simple and amazing examples.)
• KevLinDev: lots of examples and tutorials
• SVG Basics Tutorial
• SVG.org

You could also search the web for SVG, new sites and resources pop up every day.

SVG Lives: the Internet Explorer Claim

This is the next in a series of posts refuting some recurring claims about the death of SVG, In the first post, I gave a brief overview of SVG. Each subsequent post takes a claim and refutes it.

The Claim

SVG is dead because it is not supported by Internet Explorer

This argument is possibly the most complicated. For a long time, almost the only way to view SVG in a browser was by using the ASV plugin that worked best under IE. Adobe has not improved this plugin in years and Microsoft has done nothing to make it easier to use. Meanwhile, the other major browsers (Firefox, Opera, and Safari, to name a few) have steadily been improving their native support for SVG.

At present, IE seems to be the only browser without any native support for SVG. Despite the fact that IE is the dominant browser, it's popularity has been falling in recent years (down to around 80% from the upper 90% range a few years ago). For some sites, the proportion of IE visitors is even lower.

Several companies and individual groups have been revisiting the idea of developing a new SVG plugin for IE. When one of these projects completes, users of IE would have the same access to SVG as users of other browsers.

That isn't the whole story though. SVG has actually spread in places other than the web. SVG has been growing in popularity among cell phone systems, especially outside the United States. SVG is very popular in the cartography community. Some companies are using SVG behind the scenes, because it is relatively easy to manipulate from code, and then rasterizing the results.

Once upon a time, lack of support in IE would have meant the death of almost any web format. Now, IE is not the only game on the web. More importantly, the market for SVG as a vector format has spread beyond the web to phones, maps, and even operating systems (the KDE window manager on Linux makes extensive use of SVG.)

Next time: Summary

SVG Lives: the Video/Audio Claim

This is the next in a series of posts refuting some recurring claims about the death of SVG, In the first post, I gave a brief overview of SVG. Each subsequent post takes a claim and refutes it.

The Claim

SVG is useless because it doesn't support video or audio.

It's time to go back to our original SVG definition. SVG is, first and foremost, a vector image format. Although SVG does provide some animation support, it is not a multimedia control language. The ability to play external video or audio is not necessary for doing 2D vector graphics. While this ability may be nice, it has nothing to do with SVG's design goals.

Saying this is a flaw in SVG is more or less equivalent to saying the JPEG format is useless because it doesn't support playing external audio. No one would seriously expect a raster image format to play external audio. That does not stop this claim for the death of SVG.

Many people have done very impressive work making animations with SVG. Although, the full SMIL language was designed to coordinate multimedia presentations, SVG only included a subset that was appropriate to animating vector graphics. While powerful, this subset does not include the ability to play external video or audio.

The fact that SVG has no support for video or audio playback doesn't impact its use in static vector images or even animated vector images. Despite the claim, SVG is strong and healthy.

Next time: The Internet Explorer Claim

SVG Lives: the 3D Graphics Claim

This is the next in a series of posts refuting some recurring claims about the death of SVG, In the first post, I gave a brief overview of SVG. Each subsequent post takes a claim and refutes it.

The Claim

SVG is useless because it doesn't support even basic 3D features

This claim makes a little more sense than the previous one, but not much. The focus of SVG was on 2 dimensional vector graphics. It is obviously possible to render 3D objects by projecting them onto a 2D representation. After all, that's how 3D graphics are always displayed on a monitor. You can use SVG as the 2D representation. However, SVG does not provide any particular help for projections or 3D objects, because its focus is 2D graphics..

All of the image manipulation supported by SVG is designed to support 2D vector graphics. This means that there is no support for perspectives or non-linear transforms. The painting model does not support explicit z-ordering. There is no support for 3D coordinates. None of these things are required for 2D vector graphics, so they do not exist in SVG.

There are some separate projects that target 3D vector formats (VRML and X3D are probably the most complete). X3D has even been written with a goal of being compatible with SVG.

The fact that SVG doesn't support 3D does not reduce its utility as a 2D vector image format. Despite this claim, SVG is still alive and well.

Next time: The Video/Audio Claim

SVG Lives: the Widget Claim

This is the second in a series of posts refuting some recurring claims about the death of SVG, In the last post, Reports of SVG's death exaggerated, I gave a little history and refresher on SVG. This time I will try to tackle one of the claims about the death of SVG.

The Claim

SVG is useless because it doesn't have a widget toolkit for building GUIs

This argument seems to resurface every year or so. Invariably it is floated either by someone trying to build a website completely on SVG or by someone trying to compare SVG to a GUI-building technology (recently that has been Microsoft's XAML).

The argument normally starts by asking for a particular widget in SVG. A few people will show how they have constructed something, which leads to complaints about having to actually build what are obviously primitive tools. Next come the demands for a widget set in SVG. After several rounds of emails, the person decides that SVG is completely useless, because it doesn't even have radio buttons or a text-entry field.

The important point here is that SVG is a vector image format. It was never designed to replace GUI widgets. It is just an extremely powerful format for specifying 2D images. This claim makes as much sense as saying PNG will never amount to anything because it doesn't support scroll bars and drop down boxes. Obviously, no one would make this claim. But, this reason for claiming the death of SVG keeps recurring.

Amusingly enough, the KDE window manager for Linux uses SVG extensively for graphical elements in its user interface. One reason is because vector formats are very efficient for stylized images that may need to scale to multiple sizes. This describes many of the graphical elements that display on most desktops.

The fact that SVG does not have a built-in set of GUI widgets does not detract from its utility as a vector image format. As KDE has shown, SVG can be used to build parts of a graphical user interface. That is not because it has built-in support for GUI widgets. It is because SVG supports 2D graphics and many GUI elements are basically 2D graphics with behavior.

This claim is about SVG not having support for something it was not designed for. Obviously, this is not proof that the format is dead. SVG is alive and well.

Next time: The 3D Graphics Claim

Reports of SVG's death exaggerated

A message appeared recently on the SVG Development mailing list that, once again, predicts the death of SVG. This meme comes up pretty regularly on the various mailing lists for SVG. Most of them are trolls, of course. But this one got me thinking again about what SVG is and what it is not.

I thought it might be interesting to consider some of these claims and try, once again, to put them to rest. I'll cover each claim in a separate entry over the next few posts. To do that, we need a little background material.

What is SVG

Let's start off with the basics. SVG stands for Scalable Vector Graphics. It is an open XML-based vector graphics format described by a World Wide Web Consortium (W3C) recommendation. Unlike the formats you may be more familiar with (JPEG, PNG, GIF, etc.), SVG is not a grid of colored pixels or raster format. SVG describes graphical objects through lines, curves, and manipulations of objects.

This gives a number of advantages. The first is part of the name: scalable. When you scale a normal raster format larger, the image gets worse (jaggies). When you scale a raster format smaller, you lose information. This isn't a bug, it is a property of all raster formats. Vector formats, on the other hand, are described by mathematical entities like lines and circles. You can scale them to any size without visual artifacts or loss of data.

SVG also supports three other features in addition to the scalability that is part of being a vector format. First, SVG supports declarative animation based on the SMIL W3C recommendation. Secondly, SVG supports scripting through ECMAscript. These two features mean SVG can be used for dynamic images as well as static images. Finally, SVG supports declarative filter effects that can be used to create visually complex images.

The Claims

In the next few posts, I'll explore some of these claims.

1. SVG Lives: the Widget Claim
2. SVG Lives: the 3D Graphics Claim
3. SVG Lives: the Video/Audio Claim
4. SVG Lives: the Internet Explorer Claim

Finally, I'll summarize the discussion: SVG Lives: the Summary

Ease of Development as a Quality Metric

I recently been studying software architecture and have had a minor epiphany. My assumptions about code complexity may have been unnecessarily pessimistic.

From my experiences in software development, I have observed that more powerful or more robust systems are naturally more complex. A side effect of this observation is that beginning to do development on an existing system in this category required a relatively large startup time. I have observed talented and intelligent developers taking 4-6 months to learn a system well enough that they would do less harm than good when making changes or fixing bugs. I had come to accept this as a necessary evil of complex systems.

In reviewing the concepts of accidental complexity and essential complexity for the umpteenth time, I realized that I might have been setting the dividing line in the wrong place for the software systems I've seen. What if it takes 4-6 months to understand these systems because of too much accidental complexity. Maybe a good metric would be how long it takes a competent developer with knowledge of the domain to make positive changes to the code.

In Abbreviation, Accidental Complexity, and Abstraction, Reg Braithwaite does a very good job of explaining part of what I'm seeing. Some code may develop accidental complexity through the very mechanisms we are using to develop better code. Refactoring code inappropriately or removing duplication badly can result in code that requires way more brainpower to understand. This is can be an indication of lower quality.

Recently, I've been working with some substantial systems that are actually pretty easy to understand. I see things that can be changed easily, verified, and moved into production in a short period of time. I have seen some things that can be improved to fix potential bugs. I have also seen places where better abstractions would make the code more flexible and powerful.

I wonder if that last set of changes might be better left alone. This appears to be yet another facet of YAGNI that I just had not thought through well enough in the past. As I make changes, I need to make an effort to remain mindful of how difficult it will be for the next developer to make changes. Does this new abstraction really offer enough benefit to be worth the cost of learning the abstraction? Does the change increase the quality of the code, or just add abstraction for the sake of abstraction?

I have often weighed multiple alternatives to a design to determine the simplest. I have even used the YAGNI argument to suggest that a simpler abstraction is better than a complex framework. I have made trade-offs in design to support only what the requirements ask and avoid adding unnecessary flexibility. But, I've never actually thought about trying to reduce abstraction for the same reasons.

When a system contains only the abstractions needed to do its work, it is easier for the next developer to understand and change. I need to be more aware of this application of YAGNI in the future.