Interview with Jon Ferraiolo: SVG past, present, and future
Created
15 October 2012
Vincent interviewed Jon Ferraiolo after the "Graphical Web" conference. Jon is often called the father of SVG (Scalable Vector Graphics), a standard for creating interactive, animated two-dimensional vector graphics on the web.
After spending 13 years at Adobe, Jon now works in IBM's Emerging Technologies group.
In this interview, we learn more about the early days of SVG and how the standard evolved within the wokring group that defined it. Jon also shares his views on where Web graphics are and where they are headed.
Hi Jon, it is great to talk to you about SVG. You are often referred to as the spiritual father of SVG. Can you tell us what role you played in the inception of that key Web technology?
Before the SVG activity began at the World Wide Web Consortium, I was the primary author of the PGML submission (Precision Graphics Markup Language) which served as the starting point for the SVG language. Once the SVG Working Group started up in August 1998, as sole editor of the SVG Specification, I edited every word in the SVG 1.0 specification. I was deeply involved in nearly all technical discussions in defining the SVG language and probably wrote the majority of the text and examples in the specification. On the Adobe side, I served as architect for Adobe's SVG-related product activities, including working with the Adobe SVG Viewer team. I wrote the original save-as-PGML code in Adobe Illustrator (which evolved into Illustrator's save-as-SVG feature).
So what were the origins of the SVG language?
In 1998, there were three proposals: Web Schematics (by CCLRC in UK), PGML (by Adobe, IBM, Sun Microsystems, Netscape) and VML (by Microsoft, Macromedia, Autodesk, Visio, HP)
The SVG WG decided to use PGML as starting point because it was using the PostScript/PDF graphics model (which is commonly implemented in graphics systems), it looked like HTML, and it had the important web features: scriptable, animatable, hyperlinking.
Following a two-year discussion on various detailed issues (1998-2000), we had top graphics experts from leading companies (such as Adobe, Apple, Autodesk, ILOG, Kodak, Macromedia, Microsoft, Sun, Visio) participate and talk about many delicate technical issues such as rendering/compositing models, coordinate transforms, color systems, path syntax, basic shapes to support, filter effects, animation and SVG fonts among others.
We then spent one more year to build a test suite (2000-2001) and SVG 1.0 was published on Sept 4, 2001. The SVG support currently in modern browsers is almost entirely restricted to the SVG language definition from the original SVG 1.0 spec from 2001.
Who implemented SVG viewers in the early days?
On the desktop, there were multiple implementations: the Adobe SVG Viewer (ASV), the Apache Batik SVG Viewer (Sun, IBM, Kodak, ILOG) the Corel SVG Viewer, and browsers (Mozilla, WebKit, Opera, …). On mobile there was BitFlash and Ikivo (deployed on countless feature phone models as feature phone standards required SVG Tiny), Opera, OpenWave, Motorola.
Who led the way for SVG’s resurrection within the browsers?
Opera was first to implement near-complete support in browsers. Mozilla was the first among big market-share browsers with “static SVG”, which was critical for SVG legitimacy. WebKit later delivered SVG & animation and Mozilla responded with animation support too. Then hell froze over when Microsoft added support for SVG in IE9 (but without animation support). Android was the very last to holdout, but now the Android 3 browser supports SVG too.
Have today’s browsers finally matched/exceeded what Adobe SVG Viewer 3 provided in 2001?
On a pure SVG level, implementations are close, but not as complete. On the plus side, many SVG features are now available to the HTML/CSS: CSS Animations, CSS Transforms, Gradients, filter effects, clipping and masking (coming), pointer-events.
Why is the SVG spec so enormous?
Some committee members were highly passionate about particular features. So it was sometimes necessary to say “yes” to everyone’s pet features to keep spec marching forward.
Adobe (ASV developer) was OK with the huge spec because (back in 1998-2001) it had the capacity to implement everything. Some committee members felt the huge specification was ok for browsers because SVG would be “profiled”: the hope was that browsers would implement SVG Basic instead of SVG Full. However, Mozilla implemented the whole specification. And then other browser vendors followed.
Why does SVG’s coordinate system have the Y-axis pointing down?
Yes, this is a problem because SVG angles go in opposite direction to what is taught in textbooks. Other technologies that were discussed in the working group: PostScript and Flash have a regular cartesian coordinate system (Y-up), HTML/CSS and Java2D have inverted coordinate system (Y-down).
The vote was 5-4 in favor of Y-down.
Why does SVG use XML, DOM, and XLink (e.g., xlink:href)?
This is a problem too because SVG could have been better if closer to the HTML approach. So why does SVG use those technologies? Well, for historical reasons. Back in 1998-2000 (when all the key decisions were made), the W3C leadership believed XML, DOM, and XLink were the future of the Web. WhatWG and HTML5 happened years later.
Same sort of explanation applies to some other SVG language features.
We are a lot smarter now about web development (and lots of other things) than we were in 1998-2000.
SVG and CSS – is it good that SVG is stylable via CSS style sheets?
The original SVG WG came very close to deadlock over this issue. There was about a six month delay in the original spec while arguing this question. Ultimately a compromise was found: both XML attributes and CSS properties are allowed in SVG.
I think SVG and CSS are both a good and a bad idea.
Why SVG+CSS is a good idea? Well, it allows HTML with inline SVG to have a consistent styling model. Also, commonality between HTML and SVG is generally a good thing.
And why SVG+CSS is a bad idea? It made SVG considerably more complicated to implement and has an impact on performance. Even when available, people don’t use CSS with SVG very much.
Whatever your personal conclusion, browsers have implemented SVG+CSS and it’s here to stay.
Why does the SVG spec include ….
… Animations?
Because having the viewer control the animation timing loop could make smoother animations than JavaScript .
Because the W3C wanted synchronized multimedia (looking ahead to video and audio)
And because CSS animations weren’t proposed until 2007.
… SVG Fonts?
Because SVG needed reliable high-quality fonts, and an interoperable web fonts that all browsers would implement only gained momentum in last couple of years
… <use> element and its shadow tree rules?
Because reusable symbols is a common requirement. Because we had to invent shadow tree rules (note: W3C web components with its shadow tree rules isn’t available even today)
… <use> Filter effects, additive clipping paths, elliptical arcs?
Because certain committee member(s) really wanted these features, and it was easier to say yes than no.
Jon, any recommendations for today’s Web developers who use SVG?
I would expect that people who are new to SVG would find it helpful to buy an SVG book for orientation and tips. SVG does share various things with HTML such as scripting and styling, so HTML developers should be able to figure out how to do basic SVG operations quickly, but once you get into more advanced graphics operations such as paths and transformations, it's probably worthwhile to find some good instructional material. Also, bear in mind that browsers don't support some of the JavaScript conveniences on SVG elements that HTML web developers have become accustomed to, such as innerHTML assignment and element.children (have to use element.childNodes instead). I hope that future browsers will add these conveniences to SVG elements.
If you are interested in learning more about SVG, check out these SVG resources:
+
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License. Permissions beyond the scope of this license, pertaining to the examples of code included within this work are available at Adobe.
