SVG – Graphics Markup for the Web
What is SVG?
SVG is a markup language for describing two-dimensional graphics applications and images, and a set of related graphics script interfaces. SVG 1.1 is a W3C Recommendation and is the most recent version of the full specification; a second edition of SVG 1.1 which includes clarifications and minor improvements based on developer feedback is currently in Last Call. SVG Tiny 1.2 is a W3C Recommendation, and targets mobile devices.
SVG 2 is currently under development, and will add new ease-of-use features to SVG, as well as more closely integrating with HTML, CSS, and the DOM.
Early days of SVG
Interview with Jon Ferraiolo: SVG past, present, and future
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 ….
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?
Where to go from here