We touched on the idea of Flash-challenging technology when we looked at Canvas in Chapter 9. But perhaps the most serious challenger to Flash in the past decade has been Scalable Vector Graphics (SVG), an XML format for 2D graphics and animation, which is making yet another mini-comeback. Let’s take a very brief look at the dead-again, less-dead-again technology that is SVG.

SVG, SVG…

Oh, SVG (Scalable Vector Graphics)…what can we say about you? You’re a separate W3C spec that’s been in development since 1998 (on target to be finalized in August 2014!). You’re not part of the HTML5 spec, but HTML5 will let you appear inline with other markup. You’re all about vector shapes, which makes you the Illustrator to Canvas’s Photoshop. You’ve promised so much, for so long—in 2002 people were writing 1,000+ page books about you, such as SVG Unleashed (Sams, 2002). Yet you’ve never made it to the big leagues. What happened?

SVG is both a relic of past web standards and a technology that’s finally kinda-sorta-almost arrived (just in time for the development of SVG 2.0). It’s an XML format for vector graphics (think of SVG being to graphics as HTML is to text), which means it looks like a bunch of angle-bracketed tags and attributes. Remember when we looked at the history of HTML and how it was going to be all XML? Well, SVG is part of that vision—the vision that didn’t work out.

Here’s what basic SVG looks like:

<svg id="mysvgexample" height="200" width="300" xmlns="http://www.w3.org/2000/svg">
   <rect id="myrectangle" width="200" height="100" fill="red" x="20" y="20" />
</svg>

This renders what you see in Figure 11-1.

Yep, a red rectangle. I’ll give you a moment to recover.

Here’s a quick explanation of what’s going on here: we’ve set the <svg> element to be 200px high and 300px wide, which acts as a transparent container for the shapes or lines we want to render. (I’ve given it a border with CSS so you can see its boundaries.) We then create a rectangle with the <rect /> element, give it a height and width, and give it an x and y offset from the container <svg> element. Add a fill (I’ve used the keyword red, but you could use a hex value too), and we’re done.

In HTML5 you can drop this code right into your HTML document, and supporting browsers (IE9+, FF4+, Safari 5.1+, Chrome 7+, Opera 11.6+, iOS 5+, Android 3+) will render it as appropriate.

SVG: Browser Support Arrives at Last

SVG is interesting again because browser support is finally arriving. Currently, all modern and not-so-modern browsers, including IE9 (but excluding, you guessed it, IE6–8) and Android browser 3.0+ (but not 2.x or older), support SVG embedded using the <embed> or <object> element. The IE situation isn’t quite as bad as it sounds, though, as we’ll see next.

Browsers are also starting to support SVG images in the <img> tag and even as CSS backgrounds (specifically IE9+, FF4+, and all recent Safari, iOS, Chrome, and Opera releases).

And there’s even great support for applying advanced SVG features such as filters (for example, Gaussian blur), clipping, and transforms to non-SVG objects. Amazingly, at the time of this writing, all of the major browsers on both desktop and mobile now support this; that’s a huge improvement from just a year or two ago when support was varied and spotty.

Things get a little less rosy on the more advanced features. At the time of this writing, SVG SMIL animation isn’t supported in IE on the desktop or mobile; SVG transform and transition effects aren’t supported on any of the mainstream mobile browsers; SVG fonts aren’t supported in IE, Firefox, or mobile Opera; CSS filters for SVG are available only in WebKit browsers (including Opera); and SVG Fragment filters are available only in non-WebKitbrowsers (IE and Firefox). For up-to-date information on what is and isn’t supported in SVG, check out http://caniuse.com/#search=svg.

Support for basic SVG including filters and inline elements has come a long way in the past few years. But in order for SVG to become a major contender and move beyond just drawing static images, it needs full support for advanced animation, CSS transitions, and fragment shaders. Adding to the dilemma, most web designers and developers can’t afford to abandon everyone who isn’t in the latest browser. A huge portion of the web-browsing population still uses older browsers, and if we rely on dynamic SVG effects out of the box, we’ll be abandoning those people to a graphics-less world.

So, what do we do? Is there any way to start using SVG now without having to mess with all this cross- and legacy-browser nonsense? Luckily, there is.

Yes, There Is Real-World SVG We Can Use Right Now

Dmitry Baranovskiy is SVG’s hero and savior. He has authored two JavaScript libraries that let designers take advantage of everything SVG can do without having to manage all of the complexities themselves. Both are sponsored by Adobe, who is Baranovskiy’s employer at the time of this writing and who has been pushing SVG features to spec through the W3C with a lot of success over the past decade or so.

Baranovskiy’s first library is called Raphaël, and it provides SVG compatibility all the way back to IE6. Raphaël lets us do some simple, cool, Flash-like things with SVG. Under active development for several years, it offers browser support right down to IE6 (thanks to VML translation in IE). You can check it out here: http://raphaeljs.com/. (And make sure you check out the sister graphing library, gRaphaël, as well: http://g.raphaeljs.com.)

His second library is called Snap.svg, and it trades legacy support for more advanced features that work in all modern browsers. Snap was written entirely from scratch and works on SVG elements loaded from anywhere (in the page, downloaded to the page through a file, loaded from text input…whatever). It’s free and open source; check it out here: http://snapsvg.io/.

We’ll look at what SVG can do both by itself and through these libraries in a moment, but for now it’s worth keeping in mind that, thanks to Dmitry, simple SVG (including animation) can be used with broad browser support.

Imagine if, all of a sudden, we had to support devices with an extremely wide array of resolution sizes and densities, some of which didn’t support Flash. Wouldn’t vector graphics—crisp at any resolution and scalable to any size—make life a lot easier? Hold that thought....

The Many Faces of SVG

Let’s look at the different faces of SVG.

• SVG, the gigantic spec that’s been kicking around (and growing) for a decade
• Advanced SVG as it’s being implemented in cutting-edge browsers
• SVG as we can use it today in real-world situations with tools such as Raphaël and jQuery SVG (http://keith-wood.name/svg.html)

SVG can be (and is being) used right now for a variety of situations with solid cross-support, including iOS devices, so its time may have finally arrived. And it’s just in time, considering Adobe’s abandonment of Flash in mobile browsers and its promotion of Snap.svg. (For more on the death of Flash, see the discussion in Chapter 9 where we looked at Canvas and Flash.) And that’s not to mention the pressing need for interface elements that can scale up from a phone to an iPad Retina display to a 27" or 30" screen.

SVG in the ’00s: The Great Hope That Wasn’t

SVG has been on quite a journey. In its full pomp, it’s extremely impressive and currently does as much (if not more) than current CSS3 implementations. Full SVG support does everything from animation to the Photoshop-like filter effects we touched on earlier (see this example in Chrome, Opera, or Firefox: http://svgwow.org/filterEffects/chiseled.svg) to custom fonts, masking, video, and of course drawing vector shapes. It’s all there (in the spec at least—browser support has lagged badly). So, in a way, it’s a lot like Flash.

Well, basic SVG is like Flash a decade ago but without the browser support or developer tools. In fact, before Adobe bought Macromedia (which developed Flash), Adobe was championing SVG as an open alternative. And in 2002 some 160 million people were using their SVG viewer plug-in (since discontinued; see www.xml.com/pub/a/2002/07/03/adobesvg.html).

To give you a taste of the hype around SVG in the early ’00s, here’s a quote from a 2002 article on Digital Web titled “SVG: The New Flash” (www.digital-web.com/articles/svg_the_new_flash/):

But SVG never really took off. (Let it be said its “nonproprietary nature” hasn’t counted for much in the past decade.) It couldn’t touch Flash’s installed base and never had a development tool as designer-friendly as Flash. And when Adobe bought Macromedia in 2005, as far as vector graphics on the Web went, it was Flash or bust.

Still, SVG never really died either. And with browser support now improving rapidly and the writing on the wall for Flash, perhaps SVG is due for yet another comeback.

SVG Browser Support: Android, What the Hell? Oh, and IE…

One sticking point at the moment is that Android 2.x doesn’t offer even basic SVG browser support, despite Google pushing SVG elsewhere (see http://googlecode.blogspot.com/2009/10/svg-at-google-and-in-internet-explorer.html). That might seem like old news considering that at the time of this writing Android is on version 4 and heading toward 5, but thus is the plight of Android: somewhere around 24 percent of the Android world is still using Android 2 as I type this (for up-to-date stats, see the Android developer dashboard: http://developer.android.com/about/dashboards/index.html). Basic SVG support has been in WebKit, the engine behind Android’s browser, for ages; it was just intentionally left out of Android 2.x “to save space” (see the comment and discussion here: http://code.google.com/p/android/issues/detail?id=1376#c4). Go figure. Android browsers in 3.x and 4.x support basic SVG just fine, and most of the advanced features are finally available in 4.4. (aka “KitKat.”)

Fortunately for us, there are several libraries available that allow us to translate modern SVG into something IE6-8 (and any other browser) can understand.

Raphaël, the JavaScript library for working with SVG we touched on earlier, falls back to IE’s old Vector Markup Language (VML) for compatibility. (It’s similar to the Canvas emulation we looked at in Chapter 9 and has similar limitations; in other words, VML is slow.)

There’s also SVG Web (http://code.google.com/p/svgweb/), which translates SVG to Flash for older browsers that don’t support SVG, including IE. (Sadly, this still doesn’t help us out with Android 2.x. See http://groups.google.com/group/svgweb/browse_thread/thread/77fb6970f5f01e97.)

There’s also canvg (http://code.google.com/p/canvg/), which renders SVG in Canvas and provides some SVG support for Android as a stopgap measure until Android 4.0 becomes widespread. This approach is discussed here: www.kendoui.com/blogs/teamblog/posts/12-02-17/using_svg_on_android_2_x_and_kendo_ui_dataviz.aspx. (Fabric.js may also help: http://fabricjs.com/.)

While these tools make basic SVG a reality for just about any browser, remember this is only basic SVG, not the crazy Photoshop-like filters that have become part of the SVG spec.

SVG Demos: What Is It Good For?

Vector graphics are useful in lots of instances, such as maps, charts, illustrations, logos, visualizations, resolution-independent interfaces, and so on. And the success of Flash has certainly demonstrated that the need for animated vector graphics is there. What may otherwise be delivered in Flash can potentially be done in SVG and therefore be available to iOS users.

Let’s take a look at some SVG demos to see what it is capable of. We’ll look at a few general examples and then a few real-world Snap.SVG and Raphaël examples.

Snap.svg-Powered Demos

Much of the current, real work for advanced browsers is done with the library Snap.svg, which, as we saw earlier, offers a simple and easy way to generate, manipulate, and animate SVG elements.

Snap.js is amazingly powerful, and many sites are moving in that direction for animation. Yet legacy browsers are still out there, and many of us need to support them. To get the most out of SVG without leaving legacy users behind, Raphaël is the library of choice. Let’s look at how it’s being used.

Working with SVG

Given browsers now support SVG files in <img> tags and even as CSS backgrounds, we can now use SVG files for background gradients, tab backgrounds, and other image elements where a single file can be reused and scaled as needed (see this demo: http://css-tricks.com/using-svg/). Combine SVG’s flexibility with CSS3’s multiple backgrounds, and there are interesting things afoot when it comes to styling visual elements. For example, SVG would be great for styling the controls of a media player for <video> and <audio> elements.

This isn’t just theoretical—designers now use SVG seriously and provide tutorials to get us up to speed. For example, in “A Farewell to CSS3 Gradients,” Alex Walker looks at the patchy support for CSS3 gradients, suggests we consider SVG as an alternative, and provides a handy tutorial to do just that: http://designfestival.com/a-farewell-to-css3-gradients/.

Responsive Web Design and SVG

Vector graphics may also prove quite helpful in responsive web design situations where we want to display crisp, lightweight interface elements on everything from the mobile to the desktop (and especially on super-high-resolution iOS and Android [3.0+] screens). Again, this isn’t theoretical; designers are getting their hands dirty with this right now. In Smashing Magazine’s January 2012 article “Resolution Independence With SVG,” David Bushell looks at using SVG for interface elements: http://coding.smashingmagazine.com/2012/01/16/resolution-independence-with-svg/.

Vector UI elements are not a free responsive lunch, however. While it’s tempting to think they can scale up and down effortlessly (they’re vectors!), this isn’t necessarily true. Large artwork scaled down to very small sizes can become a blurry mess, and small artwork scaled up can look spartan and devoid of detail, as this lengthy article on icons and SVG demonstrates: www.pushing-pixels.org/2011/11/04/about-those-vector-icons.html.

(Of course, CSS3’s support for gradients, rounded corners, transformations, and animation may place the proverbial pillow on SVG’s face just as it comes off of life support for the third time. In fact, SVG filter effects are being ported to CSS and are already in WebKit, as this article explains: www.html5rocks.com/en/tutorials/filters/understanding-css/. Plus, check out these crazy demos of SVG-inspired CSS shaders: www.adobe.com/devnet/html5/articles/css-shaders.html.)

Despite that SVG has been kicking around for more than a decade, the web design community hasn’t really given it a thorough workout to see what’s possible until recently. So, with the renewed interest in all things web standards, the decline of Flash, the rise of responsive web design, and a reasonable baseline of browser support, it’s definitely time to get experimenting again.

SVG Gotchas

There are two key problems, though. The first is performance: complex SVG is slow. Browser makers generally haven’t paid much attention to SVG performance because it was always the red-headed stepchild of web standards. Things are starting to change, however. For one, hardware acceleration helps dramatically, as Microsoft has demonstrated with IE9–11. (Yes, Microsoft has not only caught up but is now leading the way in some areas of web standards implementation. You’re telling me!)

The other problem is tools. No one wants to sit around writing SVG markup by hand. Some drawing tools are available, however, such as the following:

• Inkscape, an open source, cross-platform vector drawing program that uses SVG natively, is here: http://inkscape.org.
• Adobe Illustrator supports SVG, and you can read more about support for SVG here: https://helpx.adobe.com/illustrator/topics.html. See “SVG” halfway down the page.
• Janvas, a framework for interactive graphics in SVG, is at www.janvas.com/.
• Method, an online SVG image editor, is at http://editor.method.ac/ and is open sourced at https://github.com/duopixel/Method-Draw.
• SVG-edit is a “fast, web-based, JavaScript-driven SVG editor” that’s free and open source, which we looked at earlier. You can try it live at http://svg-edit.googlecode.com/svn/branches/2.5.1/editor/svg-editor.html, or you can download it at http://code.google.com/p/svg-edit/ (see the links to browser add-ons, too).
• A variety of other tools are listed here: http://en.wikipedia.org/wiki/Scalable_Vector_Graphics#Software_and_support_in_applications.

You can also use JavaScript libraries such as Snap.svg, Raphaël, or jQuery SVG to draw SVG with JavaScript. Nevertheless, most vector drawing and animation for the Web is done in the Flash IDE. What if Flash could export SVG?

SVG: Heir to Flash?

Adobe’s dedication to pushing SVG forward, both in the standards community and through support of frameworks such as Snap.svg and Raphaël, is admirable and speaks to its desire for a post-Flash Web. For many, many, many years Flash was the only and preferred solution for bringing animated, interactive elements to the Web. Those elements were locked inside a tiny plug-in element, though, and communicating with them or manipulating them was difficult. Want a dynamic and animated navigation for your site? Well, you might as well build the entire thing in Flash because using it for just the navigation frame was a royal pain.

Yet Flash was (and continues to languish as) much more than simple animations. It was a fully fledged solution for multibitrate-encrypted video streams, a high-powered gaming engine, a 3D engine, and so on and so forth. As we saw in previous chapters, there are many different technologies hiding under banner of “HTML5,” and most of them will take a piece of Flash’s territory. SVG has been coexisting with Flash for a long time, and now it’s finally coming into its own.

The question for SVG isn’t whether it can (or should) replace Flash as a solution for constructing interactive and animated page elements but whether it can carve out a niche truly of its own. Snap.svg and Raphaël have certainly helped it carve out that niche, and in the next few years as the browsers mature we’ll be able to do more with SVG natively.

Can SVG generate enough interest in the design community after crying wolf in the early ’00s? Ironically, it may not be Flash that distracts the web community from SVG but other web standards. With so much activity around web standards development these days, it has a fight for attention on its hands.

Is SVG destined to always be the bridesmaid and never the bride? Or will the folks who wrote the huge tomes on SVG all those years ago get to dust off their work for a belated second edition? Time will tell.

In the meantime, it’s easy to get started with Snap.svg or Raphaël, so why not give them a try? Check them out at http://snapsvg.io and http://raphaeljs.com.