Last week, I published the first draft (and subsequent updates) of the Web Interface specification, which defines touch events. This is the first spec from the new W3C Web Events Working Group.

Peter-Paul Koch (PPK) gave it a positive initial review. Apparently, others thought it was news-worthy as well, because there were a few nice write-ups in various tech sites. Naturally, cnet’s Shank scooped it first (he has his ear to the ground), and it was fairly quickly picked up by macgasm, electronista, and Wired webmonkey.

I thought I’d go into a few of the high-level technical details and future plans for those who are interested.

Touch interfaces are nothing novel, nor is using them with Web content, but there are enough differences from mouse interaction that specifying them should lead to easier development and better user experiences on the Open Web platform (or in HTML5 webapps, if you prefer that buzzword).

The most important thing to note for multi-touch events (using more than one finger, say) is that you want the different touch-points to be considered together, not as completely unrelated events. The WebKit implementation, used in the iPhone and Droid smartphones, as well as many, many others, used a good model for this, with each event exposing lists of currently-active individual touch-points; with wide deployment of WebKit already, it was an obvious starting point. PPK’s blog post was off on one minor detail here: while I did base the spec on WebKit’s behavior, I didn’t base it directly off of Apple’s documentation; I wrote it from scratch, for better or worse, and extended it for broader applicability.

One of these extensions was to take PPK’s suggestion to add ‘touchenter’ and ‘touchleave’ events, the equivalent of the ‘mouseenter’ and ‘mouseleave’ events that we finally specified in DOM3 Events, which work much more intuitively than ‘mouseover’ and ‘mouseout’.

I also extended the WebKit model to add ‘radiusX’ and ‘radiusY’ attributes, to indicate the general size and shape of the thing that touched the surface… say, a fingertip or a stylus (a fancy way of saying “pen-like stick”), described as an ellipse. I’ve been soliciting use cases and requirements for a couple of years, and this is meant to cover a similar request across different devices.

That leads me to mention the other use case for this specification: pen-tablets. Almost a decade ago, I was writing a browser-based SVG editor called SVG-Whiz (long since decomposed into digital fertilizer), and I wanted to be able to use my Wacom tablet with it. It worked okay as a mouse replacement, but I had to choose the stroke-width manually… I couldn’t use the tablet’s built-in pressure sensitivity.

We’re about to change that. Another change to the WebKit model is the addition of a ‘force’ attribute to indicate the level of pressure used on the touch or tablet interface. This will be useful for SVG or Canvas API drawing apps, games, and myriad other purposes. For example, most touch screens don’t have the capability to detect hovering (some capacitive screens being the exception)… this is a challenge for accessibility, but perhaps the pressure sensitivity—expressed in the ‘force’ attribute—could be applied to that end. We may specify a new related CSS mode, or simply define when existing ones apply, such as triggering the CSS ‘:hover’ pseudoclass past a certain pressure threshold (device-specific and user configurable, of course).

(On the subject of new CSS properties, Nokia has made the suggestion of haptic feedback properties for touchscreens, based on their implementation. This could be a very interesting addition to touch interfaces, even if it’s not available on all devices. That work would be handled by the CSS Working Group.)

In addition to pressure-sensitivity, pen input has other characteristics that distinguish it from touch, including the angle of the pen, so we may add that as well. Pen-inputs, either through tablets or stand-alone digital pens, often include particular mode-shifting buttons, so we have added attributes to detect when the alt, shift, and control keys (or buttons) have been pressed.

So, to cover a wide range of devices, we will be defining some capabilities beyond basic touchscreens: multi-touch, touch area, force, perhaps pen-angle, and even haptic feedback. Not every feature will be available for every device, but they will be useful for those that do, but we want the spec to be future-proof and device-independent.

This leads me to another touchy area: gestures. One of the common requests I’ve gotten is to add events for specific gestures, like pinch, swipe, twist, flick, etc. There are two problems with trying to standardize this right now:

1. Each device and each platform has its own gestures, sometimes several to do the same thing, and there is still room for innovation there;
2. It’s a patent minefield.

Instead, we intend to specify higher-level “intentional” events, like zooming in or out, panning, navigating, editing, etc., and define a way to map between the physical actions (touching the screen and moving your fingers) and the intention event (zooming in); it also means we can map between input on other devices, like keyboard and mouse, and the intent behind those actions. An additional aspect of this is another proposal by Nokia, the transform action events; these match the transforms in SVG and CSS, such as translateX and translateY, scale, and rotate, and add the ability to detect the rate of the actions. Having all these high-level events will ultimately make it much easier to author content and applications that work on multiple devices.

And though gestures are different on each device, we do plan to create an informative document detailing some common ones, perhaps something like the excellent Touch Gesture Reference Guide by Luke Wroblewski, Craig Villamor, and Dan Willis. That might eventually lead to some industry consensus about future efforts to define gesture events.

Last but not least, one of the additions I made to the spec after the first draft was to add my co-editors, Sangwhan Moon from Opera and Matt Brubeck from Mozilla, both of whom have already made excellent suggestions we’ve integrated into the spec, and who have volunteered to help me write the spec. It’s a positive sign that we’ve got active participation from so many different browser-engine developers, since interoperability here is the most important thing.

For me, this specification has been about a decade in the making… it’s one of the things I wanted to tackle when I first came to W3C, even before I worked there. So, I’m very excited to finally be doing it, and to help make touchscreens and pen-tablets part of the Open Web platform. With some hard work and a little luck, we could get this spec completed and implemented in browsers by early next year.

So, if you are interested in helping us make sure the Touch Interface spec meets your needs as a user, developer, or implementer… get in touch!

Text in SVG is text. Visually, you can use webfonts like WOFF or SVG Fonts (where they are supported, like in Opera or the iPhone) to make it look cool, and you can style both the stroke and fill to make it all fancy, or apply filters to pop it out or make it glow or give it a dropshadow, but it’s not just a raster image like many text headers… it’s human- and machine-readable text, as nature intended.

So, SVG is translatable, right?

I wanted to make that point in my talk yesterday at Web Directions East, here in Tokyo, so I thought I’d translate my slide on text in SVG
in real time (note: click the down arrow to step through the bullet points). But testing it beforehand (I’m glad I did some prep), neither Google nor Bing even try to translate it. Yahoo’s Babel Fish at least returns the original page, though it doesn’t take the extra little step of doing any actual translation.

Lame.

Why don’t they translate it? Bing offers this helpful explanation:

What text formats are supported?
Html and Text. The viewer will not translate text on images, in PDFs, or in Flash graphics and animation. It may also not translate some dynamically generated text, such as in cascading menus.

I expected this to work, since Google now indexes SVG; as I mentioned in a previous blog post, I made a test page back in 2002 that sorta conflated the two services, indexing and translating. But obviously, these are two different tools, and need to be fixed separately.

It would be easy to fix, I’d expect… simply add SVG to the list of allowed file types, and translate the text content of each element, just as they do with HTML. If they actually special-case different element types, that would add slightly more work, but not a lot… just as with the task of indexing, you would pay attention to the content of the <text>, <tspan>, <textPath>, <title>, and <desc> elements.

It’s ironic that this doesn’t work, because on my way back from Lyon last week, I happened to meet Bert Esselink, the author of a book on localization who works for the translation company Lionbridge, and he and I chatted about how they use SVG extensively for their translation work.

In the end, I just had a native speaker translate a couple of text passages (the automatic translations were apparently not very good) and included them in my slide, just to serve as a placeholder. But I’m hopeful that soon I can demo the automatic translation live. It would be especially useful to people looking at SVG infographics, to be able to see charts and graphs in their native tongue.

Korzybski remarked that “the map is not the territory”, reminding us that we shouldn’t confuse our mental models for reality. But maps, and data visualizations of all kinds, are really powerful, conveying complex ideas easily, and even shaping (or misshaping) perceptions about facts. This is one reason why decentralization of mapping resources and services is good; no one organization should control our common maps.

SVG is a natural fit for mapping. There’s even a detailed proposal by KDDI’s Satoru Takagi-sensei for tiling, layering, and coordinate resolution that fits on top of SVG, which I’d like to see standardized.

I’ve had an idea for a small open-source project for a while, which I’ve discussed with the brilliant Andreas Neumann of Carto.net; he’s been too busy planning SVG Open every year to help out with it thus far, and I don’t have the skills to do it without a great investment in time.

The idea is simple: there are lots of static SVG maps of various countries, states, etc. that are freely available (for example, on Wikipedia). Some effective data visualizations can be made with these (color-coding countries, etc.), but they are by necessity very simple. Content creators can’t use such maps to pinpoint specific locations (long/lat), because they don’t know the projection… the maps are purely visual, not topographical (if that’s the right word).

There are more heavy-weight solutions, like OpenStreetMap, which is awesome, but more than most people need for very simple location-sensitive webapps.

What I would like to do is have a very simple set of basic maps, with low-to-medium level of detail, all with the same projection, and to provide a Javascript utility that converts back and forth between long/lat and the coordinate space of the image. There would be one world map, and a map for each country, and a map for each major region within each country (in the US, this would be states).

For example, using this script and some of these premade maps, I could make a little webapp that allows members of a social network (e.g. a developer community, or people who share a hobby) to type in their location (long/lat), and it would stick a “pin” in the map at that location. They could see the high level overview at the world level (100 people in the US, 20 in Japan, 72 in Europe, etc.), and easily drill to the country level (click on US and open that map, showing 20 in California, 5 in North Carolina), and drill down again to the region level (showing the distribution of pins in North Carolina).

It would not go down to the city level, or show regional features like roads or lakes… that gets too complex, and there are other applications to do that. However, it would include projection metadata and instructions for each region (which the conversion script might use), and the project would make it possible for someone to export their own GIS data into this simplified format by providing instructions (for, say, ArcGIS).

This is something I think could appeal to people on a very high-level, making SVG easier to understand and use for simple projects like this; I want to improve the reusability of SVG in this way.

And I think the stellar Michal Migurski of Stamen Design, and SimpleGeo, have just scooped me. I haven’t looked into the details yet, but they just announced the launch of PolyMaps, a free and simple SVG and Javascript mapping library. Curse and bless you, you maptastic bastards!

Oh, and in case PolyMaps doesn’t completely fit what I described above, let talk.

SVG paths have a pretty good set of shape commands, enough to let you draw any 2D shape you might want in an authoring tool: horizontal, vertical, and diagonal straight lines, elliptical arc segments, and cubic and quadratic Bézier curves. Béziers are great, giving you precise control over the position and curve interpolation of each point in a concise format, using control points (“handles”), and are easily chained together to create complex shapes.

But let’s say you have a series of points, and you want to draw a smooth line between them, e.g. for stock data, an audio wave, or a mathematical graphing equation. Béziers are not as handy there, because not all the points needed to define a Bézier spline are on the curve itself. Obviously, you can decompose any set of points into a set of Béziers, but that takes math, and who wants to do that? (Put your hand down, nerd. I’m talking to the normals.)

Sometimes, you just want to lay down a set of points, and let the browser draw a smooth curve (unlike polylines, where each segment is just a straight line between the points). Like this:

Mouse over the line above to see the equivalent cubic Bézier points. They are off the line. Off the line! Oh, Math, why do you do this to me?

One thing that’s always bothered me about SVG… there should be more simple ways of doing things, and this is one of things. Over the years, I’ve idly asked math-minded folks about how to achieve this, and the answers always soared right over my pointy little head. I probably didn’t ask the question the right way.

But a few months ago, I was chatting with Ben Fry, one of the creators of Processing (the graphics programming language), and he mentioned Catmull-Rom curves as a possible solution. I took note of that, and later read up on them; they seemed a pretty good fit for my use case. In my spare time I looked for any libraries out there to convert Catmull-Rom curves to Bézier splines; I found references that talked about the the conversion using inverted matrixes, but no simple code to be had. I’m lazy, and busy, and the problem wasn’t urgent, so I kept putting it off.

But in talking to folks about SVG throughout the UK, including designers, the thought kept running through my mind that SVG really does need a better authoring experience (and I don’t just mean authoring tools, though some nice animation tools would help). So, when I got back home from vacation, before I really got back into the thick of the dozen other things I should be doing, I put on some music and spent a few hours after work scouring the intartubes for some suitable code. And as luck would have it, Maxim Shemanarev’s Anti-Grain Geometry library contained a single simplified conversion matrix and a line of code that did the grunt work in C++, easily ported to Javascript; whip up a custom parser for the <path> syntax, feed it into the convertor function, and you’ve got yourself a working proof-of-concept.

Here is a scientific chart showing how awesome the SVG <path> element is, with values derived from the overall awesomeness by different path commands, rendered using an experimental Catmull-Rom path command:

As you can see, adding Catmull-Rom curves would increase the awesomeness of SVG paths by almost 50%. That is a lot more awesome!

The syntax is pretty intuitive… it’s just the command ‘R’ followed by a set of coordinate points:

  <path stroke="#BADA55"
        stroke-width="2"
        fill="none"
        d="M20,380
           R58,342
           100,342
           100,300
           140,250
           190,210
           220,197
           250,184
           280,155
           310,260
           404,20"/>

And the path syntax isn’t just used for the ‘d’ attribute of <path> elements. It’s also used for laying out text-paths, and the shapes of SVG Font glyphs. And it’s used in animation, both for motion paths and (in the case of Béziers) for timing functions in the ‘keysplines’ easing attribute that controls the rate of animation. So, making it easier to hit specific points for paths could have side benefits for all those uses as well.

I’m really interested in feedback from others on the usefulness of this idea. I’m not married to the idea of Catmull-Rom curves specifically (Fun fact: Ed Catmull is now the president of the Walt Disney and Pixar animation studios; I believe Rom became an astronaut, was captured by aliens and turned into a cyborg, and is now a Spaceknight), just in the idea of adding this type of point-on-the-path command. So, if you support the notion of adding this in SVG 2, or have a better idea along the same lines, send an email to the SVG Working Group’s public list, www-svg@w3.org, to let us know.

The javascript library I wrote to demonstrate this is, of course, open source, available under the MIT or GPL licenses. Feel free to play around with it, and improve it to make a better proposal. You’re welcome to use it for other purposes, but I intended it just as a quick-and-dirty prototype to solicit feedback about extending SVG, so the code isn’t that great.

Update 1:

Erik Dahlström, Chief Vectorizer at Opera and chair of the SVG WG, posted a visual reply, which WordPress filtered, but I’ve now restored this inline. Nothing to see here, move along.

Update 2:

Here is my Catmull-Rom code trying to achieve the nice curves of Spiro, as suggested by Dave Crossland in his comment:

Update 3:

Looking at Spiro curves a bit closer (just the image, not the code), it seems that there are actually different node types illustrated, not simply an undifferentiated set of coordinate points as in my interpretation of the Catmull-Rom algorithm. This means that, from an syntax standpoint, those segments would need additional parameters in addition to the coordinate points on the curve, which somewhat undercuts the simplicity.

Given that SVG already has a ‘Lineto’ command, I set out to see how closely I could match the letter “a” in Raph Levien’s example, using just my Catmull-Rom and Lineto segments, and with minimal effort:

Mouse over the raster image to hide the SVG path. There are definite artifacts, and I am running into some known limitations of my script implementation in how it interpolates the last coordinate segment, but with not much effort, I was able to get pretty close.

This is not to belittle Spiro at all… Spiro generates painfully elegant curves. It’s just to compare apples to apples.

Recently, a browser implementer asked me for examples of SVG. He was having trouble finding good examples of SVG in use, particularly as parts of an HTML document. This question has come up again and again, actually, and it always vexes me. I’ve been active in the SVG community for close to a decade, and I’ve seen thousands of amazing SVG files (and many more of mediocre to average quality), but somehow they seem to have disappeared or bitrotted over the years. Some of those files only worked with the slightly-unstandard Adobe SVG Viewer, or didn’t quite work with Firefox’s incomplete support, I know, but surely not all of them. Where is all the great SVG content I remember, the games and GUIs and design and development? Where are all those files to be found?

I hear some browser implementers say that people just don’t use SVG. Intuitively, this feels false to me, based on my own experience. But could it be true?

The statistical insignificance of SVG is often cited by some people in the WHATWG, based on a large dataset of Web content indexed by Google. In the WHATWG, where HTML5 started, great stock is placed on statistics, particularly those conducted by the editor, Ian Hickson, a Google employee.

There’s no question about it: HTML is the king of the Web. I did some rough calculations, similar to claims I’ve heard before, by counting the number of returns for HTML files versus SVG files. A search for the filetype “.svg” yields around 18,165,500 hits on Google. (Note that this doesn’t count the false hits on the word “SVG” from St. Vincent and the Grenadines, Stan Van Gundy, the Sexy Valley Girls, or any of the numerous other bizarrities that the acronym stands for.) SVG content makes up just 0.106% of all Web content, by my rough estimation. Flash is almost 5 times as common as SVG. That’s pretty grim for SVG.

But wait, let’s put that into perspective. Flash is about 4.8 times more common than SVG. HTML is roughly 838 times more common than SVG. 838 times. Flash content comprises approximately 0.52% of all Web content, and HTML is roughly 189 times more common than Flash. So, Flash is clearly much more popular than SVG (even when you consider that some large percentage of Flash content is actually just encapsulated video content, these days). But that doesn’t mean that nobody’s using SVG. Nearly 20 million documents is pretty impressive, actually, especially given the fact that SVG has been hindered by a lack of native support in browsers for most of its existence (and more recently, even poor support by the Adobe plugin for IE), and a lack of common authoring tools for dynamic content (Inkscape is an excellent vector editor, but it doesn’t yet do animation or interactivity).

Eighteen million documents. That’s a lot of files. So, given that, why is it so hard to find SVG content?

Maybe because the most popular search engine in the world, Google, doesn’t index SVG.

Indexing SVG

A long time ago, back in 2002, I made a page discussing my experiments with text search and translation. The results were not very encouraging, but I reckoned it was just a matter of time. I optimistically wrote to Google to encourage them to enable text search and translation of SVG files.

8 years down the line, things don’t seem to have changed much on that front.

To be fair, many SVG files don’t contain any text at all, not even a <title> element, so indexing them might not yield much. But many other files do have at least a title, and SVG infographics and webapps usually have at least labels that might be meaningful as search terms. Often SVG files are even text-heavy.

It’s not that Google doesn’t take note of the files… obviously, you can search for the filetype, or in the worst case, the specific file URL, and normally get back positive results.  But Google doesn’t seem to search the contents of the SVG files and present them in the relevant result set.  To test this, I tried searching for a few files that I knew to have indexable text content.

As an example, I looked for some SVG files on my little (long out-of-date) SVG promotion site, SVG-Whiz.com. First, I searched for a file I knew to have a cogent block of text, my explanation of the distinctions between ‘display’, ‘visibility’, and ‘opacity’, called HideShow.svg:

This file has been hosted on my site since 2003, I’ve gotten several positive comments about it, and a direct search for that file URL turns up a few hits linking to it, so it’s seems like a reasonable candidate for indexing. But what are the results of my in-site Google search for the word ‘opacity’? Okay, that just turned up the explanation page linking to the SVG file in question. Fair enough, maybe Google doesn’t treat SVG as a “document” file, only as an image. So, how about an image search for the same term? Nada. So, maybe Google doesn’t consider SVG to be either a “document” nor an “image”… let’s search for the word ‘opacity’ in the site ‘svg-whiz.com’ with the filetype ‘svg’. As specific as that is, at the time of writing, I got not a single resulting hit.

Google can find the files… why doesn’t it do something with them?

Comparison of File Extension Frequency

So, what criteria does Google use to decide which file types it is going to index?

The Google FAQ on search filetypes lists 23 file extensions that it indexes, and says:

There are 13 main file types searched by Google in addition to standard web formatted documents in HTML. The most common formats are PDF, PostScript, Microsoft Office formats [...] Google is also scouring the Web for additional file types that are very rare. You may see them pop up in your results from time to time. [...] PDF formatted files are the most popular after HTML files. PostScript and Microsoft Word files are also fairly common. The other file types are relatively uncommon by comparison.

So, I took the liberty of conducting my own survey of the relative frequency of various filetypes, as collected by Google itself, by using the “filetype:extension” query term. I’m not totally convinced this is at all an accurate means to collect and analyze the data, but it’s what I had at hand.

I put together a table that compares the different file types that Google explicitly mentions. (I thought about representing the data as an SVG barchart, but I was afraid it wouldn’t be indexed… just kidding, the sheer volume of HTML files would make every other bar just a blip.)

I also threw in some other filetypes of interest, including some with functional similarity to SVG, such as Illustrator, PhotoShop, and Silverlight. I expected non-Web filetypes such as Illustrator’s “*.ai” to be disproportionately underrepresentated in the results compared to their actual usage, and that was indeed borne out; it’s hard to know what percentage of SVG files are intended for and presented on the Web (I’ve spoken to many Inkscape users who only use SVG for print or local hard-drive, which surprised me), but I would guess that it is far, far more heavily tilted toward Web usage… but I still thought it would be interesting to compare.

What did surprise me was how “*.svg” compared to such ubiquitous file extensions as “*.txt”, and those for Excel, PowerPoint, and the venerable PostScript. To be frank, the results make me question my methodology, or perhaps the accuracy of Google’s reporting.

Caveat: I originally compiled this information a few months ago, and when rechecking it for accuracy, I got a surprising result. Normally, the Google search for filetype:svg returned 18,100,000 hits, but late one night, it returned only 2,000,000 hits; now, my most recent check showed around 4,300,000 hits. Jumping around in the results for an explanation, I noticed that there is a lot of duplication of Wikipedia content, and since Wikipedia uses SVG, that might account for some discrepancy. One possibility is that the lower figure represents 2 million unique documents, which are duplicated in a lot of places; the same should be said of any HTML content, and probably to a lesser extent of Flash content. I don’t know if this is the right conclusion, but it would be an interesting data point. Even with the much more modest figure of 2 million documents, I still think that represents an impressive body of work, particularly in light of the fact that SVG documents are normally authored individually, not through forum or blog software, or exporting or reformatting of email and text content as HTML.

Conclusions

I don’t think this is some grand conspiracy by Google to suppress SVG. Simple neglect is much more plausible. They don’t seem to see the value in indexing SVG. But the end result is the same: SVG seems to be statistically underrepresented in terms of access through Google searches, and thus, it is harder to find SVG content.

Relying on the results of a search engine that doesn’t index SVG, to draw conclusions about how many people are using SVG is not statistically sound. This is a bit like conducting a phone survey of English speakers in China, and concluding that nobody speaks with a Southern US accent. I reckon y’all might could see the problem with that methodology if you lived here in North Carolina.

SVG is at least as plentiful on the Web, by Google’s own reckoning, as most other file types that Google does index. Search engines, Google included, should index SVG files. They should read the text inside the file, and if the file is referenced in an HTML page, they should associate those keywords with the SVG file, just as they do with raster images. SVG files should display in image searches, as well. Here’s a list of the kind of useful content that can be gleaned from most SVGs:

• file name: while pretty primative, many files give some clue as to their contents in their name
• text elements: there are several elements in SVG that contain text to be rendered to the screen, including <text>, <tspan>, <textPath>, and <textArea>, and the content should be indexed as if it were text in any other format
• embedded HTML: HTML (and other markup) can be embedded inline in SVG, and search engines should look for that and index it as they would standalone HTML content
• links: Google, and probably most other modern search engines, give weight to files that are linked from other files, and files referenced from SVG content should benefit in the same way; the @xlink:title and @rel can help define the relationship between the files
• descriptive elements: like HTML, SVG has a <title> element that doesn’t display, but adds to the information about its parent file or element, and SVG also has a <desc> element for a longer description
• metadata: SVG can contain RDF, RDFa, microformats, and ARIA markup, which search engines are starting to pick up on these days; these metadata can reveala lot about a file, from its license information to structured content (like calendars or dates or contact info) to intent (such as ARIA roles, which will soon be expanded to include things like different chart types)

And the SVG Working Group would be happy to work with any search engine developers to make improvements to SVG 2 to help make indexing SVG content easier or more fruitful.

I’m not trying to pick on Google here (though I do note that a Bing search for ‘svg opacity svg-whiz.com’ listed the SVG file as the first hit), I’m just noting a discrepancy and an opportunity for improving the experience that people have on the Web with regards to SVG. At the very least, SVG should be recognized by Google as a legitimate file type, rather than a formata non grata.

Update

Rob Russell delivered great news to us in his SVG Open keynote. As of August 31, 2010, Google now indexes SVG and delivers it in some search results. Kudos to Google for stepping up! I’m very pleased… solid results only 6 weeks later. (I guess I should thank Slashdot, too.)

I’m really excited about W3C’s new public Audio Incubator Group, just launched today, and open for collaborators, innovators, and instigators. Go take a look for yourself, and see if you can contribute.

To celebrate the occasion, here’s a simple example of an experimental audio inteface, in the world’s first (and worst) audio synthesizer in SVG (you’ll need a special Minefield build to use it). Just click on the keyboard… it’s pretty rough still, but it shows some of the potential:

(standalone SVG file)

For some background, read on after this break…

Background

Years ago, I was one of several SVG developers interested in doing for audio what SVG did for graphics, and we talked a bit about a format we called SynthML. The old Adobe SVG viewer included an audio element for MP3 playback, and I found it really useful for adding subtle sounds for button mouseovers, clicks, and other UI effects, so the idea of programmatic control of music on the Web had intrigued me for some time (anyone remember Thomas Dolby’s Beatnik?), for enhancing user interfaces, adding ambient background music, and providing full fledged music webapps. The SynthML effort fizzled out, and while there are some interesting music markup languages (most notably MusicXML, which is more like the MathML of music), there hasn’t been much traction beyond simple recording playback.

That’s why I was so psyched when I saw what Alistair MacDonald, David Humphrey, Corban Brook, and a few others were up to while attending a Processing.js community event at Bocoup. David hacked up a special build of Gecko to add script access to the raw audio stream of the HTML5 <audio> element, and Al, Corban, and friends were building cool demos on top of it.

I immediately knew I wanted to see this as a part of the native functionality of the Web platform, across browsers. In some ways, it’s the last major missing piece from the open Web… the ability to view source and hack sound, the last commonly digitizable sensorium. I also knew that I wanted the use cases and requirements to come from the larger community, the musicians and UI designers and developers who will ultimately be the ones using this functionality to sound out the depths of what’s possible on the Web (okay, I’m corny). So, I talked with Corban, David, and Al, and we agreed that a public discussion forum would be the best way to connect with this community, to get them talking and experimenting and building and sharing.

Chris Blizzard of Mozilla was there too, co-sponsoring the event, and he was extremely supportive of getting this work started at W3C. I wrote up a charter for a public incubator group, and started knocking on doors of the browser vendors, our other members, and the wider community who might be stakeholders, to drum up interest. Pretty quickly, I got support from folks at the University of Rio (PUC-Rio), BBC, and Google; currently, a W3C Incubator Group takes a minimum of three W3C members to kick it off, though once it’s started, anyone can join. With that nicety taken care of, W3C management approved the charter, and the new W3C Audio Incubator Group (or Audio XG) was launched today!

Joining the Audio XG

I invite anyone interested in audio, music, speech synthesis, games, or other related topics to get involved, join the Audio XG, and start shaping the future of Web audio on the mailing list, and chat on the #audio IRC channel (irc.w3.org, port 6665, channel #audio). Incubator participation is free and open to anyone who wants to help out.

About the SVG Synth

My SVG synthesizer is a true product of the Web. I know next to nothing about music… I can’t play an instrument, can’t read music, don’t know music theory… I love music, but I’m a consumer, not a creator. I’d love to change that, when I have time, but I’ll settle for now for enabling others.

So, when I decided to make something with the audio API, naturally my first thought was to do something I didn’t know how to do, for which I’m totally unqualified: create a synthesizer in SVG.

I started with the HTML example from the documentation for the experimental audio API on the Mozilla wiki, and converted it to SVG (with a few missteps along the way). As it turns out, the HTML5 audio interface is exposed in Gecko (the Firefox engine) even when there is no HTML content. This was good news for me. It made it even easier to programmatically create sound with it. I suspect that this is something that lies outside any current specification, but it should be codified somewhere.

Next, I looked for a piano keyboard in SVG; I found a few on Wikimedia Commons, but they were not quite what I wanted (and in typical Inkscape fashion, were a little bloated), so ultimately I just made my own, which was trivial to do.

Next, I had to understand which notes each key should sound. So I read a lesson on keyboard basics, which sufficed for my purpose.

Then I had to figure out what the frequency of each note is in Hertz (Hz), which is what the audio API understands. It was no surprise that someone had published just such a table corresponding notes to frequency, with the companion equations for deriving them.

To put the pieces together, I took the simplest possible approach: I handcoded the keyboard (I could have instantiated it with script, because it’s very deterministic, but I favor declarative markup that can be tweaked in an authoring tool); I assigned an id to each key based on the note (C4, Af0-Bb0, etc., where “f”==”flat” and “b”==”sharp”, and the number denotes the octave); I then created an associative array with the note-id as the index and the frequency as the value, so I could look it up with the key’s id; then it was just a matter of sending the frequency to the script from the HTML example, and adding a duration timer.

Finally, just as a decorative flourish, I found a partial musical staff with a treble clef and beamed eighth-note, in SVG, of course, and tweaked it to my liking.

My tools? A Web browser with the audio API enabled (libre source), a search engine, and a text editor.

Voilà! From knowing almost nothing about formal music (I’d never even heard the term “middle C” before), I created a simple synthesizer, and learned a bit about music along the way. That’s the power of the open Web. That’s why I’m so pumped up about this new focus on audio. This one goes to 11.

I’m working with a professional designer, Michael, on some graphics for my upcoming MIX presentation.  I’ve worked with designers before on various projects, some SVG, some traditional Web design, but this is my first time working on an SVG project with someone who never used SVG before, and it’s been an interesting experience, which I thought I’d jot down for anyone interested.

Both of us have been busy with other projects, and since we are in different places (me in Chapel Hill NC, him in Atlanta GA), we have only gotten to touch base a few times.  Michael has delivered some first drafts of the graphics, which look lovely, and I decided to dig into the underlying code, confident that I could trim down the file size and thus help browser performance.

My personal graphical editor of choice is Inkscape, which is a fine tool for all its warts (though it’s a little painful on Mac, where it is hosted as an X-11 application); typically, though, I create SVG either programmatically with a script or manually with a text editor (yes, I know that’s crazy… but it can be done).  Michael, being a professional designer, uses Adobe Illustrator, and I am keen to have him use the tools he is most comfortable with.  Since I want SVG to be used by mainstream designers, I want to understand how their tools work and what their workflow is like.

So, in order to make sure that we can roundtrip the files as seamlessly as possible, while still leveraging the features of SVG, I set about today to establish a workflow with Illustrator, TextMate (my go-to text editor, with a custom SVG code template bundle), Firefox, and its native debugger extension Firebug (with its handy “Inspect Element” context-menu selection).  My goal: to make reusable icons out of some of the graphical assets in the larger image, to be referenced by SVG’s <use> element.

The <use> Element

Some earlier graphical languages, especially special-use ones such as CAD languages for engineering, architecture, or mapping, included a native symbol library.  These would normally include a variety of arrowheads, iconic symbols, line styles (dotted, dashed, etc.), and other graphical primitives.  The problem with this idea is that such symbol libraries were by necessity limited in the number of symbols, and usually only had one or two styles for each basic symbol. Not very extensible.  SVG took a different approach.

SVG has the ability to “clone” an image, to reposition or resize it, and to change some of its styling.  This works on a shape or collection of shapes, whether the image is defined in the same document, or in an external SVG file.  The mechanism to do this is the <use> element, and it looks like this:

<use xlink:href="#myImageId"
     x="100" y="300"
     transform="scale(1.5)"
     fill="cornflowerblue"/>

Translated into English, this code says,

Find the image with the id of “myImageId”, and copy it.  Move it 100 pixels to the right, and 300 pixels down.  Increase its size by half again.  Oh, and if it doesn’t already have a color, make it blue. Thanks.

(That final “/” is the part that says “thanks”, a quaint courtesy missing from HTML5.  SVG was specified in a gentler time.)

Thus, designers can provide their own symbols, in the style appropriate to the task at hand.  There are several good SVG clipart libraries that allow SVG authors to share their symbols and simple reusable images.

You can see that if you draw an image of a balloon, with several paths (the bubble, the knot, the string, and maybe a highlighting accent) and some special graphical effects (a gradient, and perhaps a filter effect) all amounting to a dozen lines of code, and you want to reuse this balloon, you don’t want to redraw it each time; it would be a waste of effort, and result in a much larger file.  For print, this may not be as much of an issue, but for a Web-based format, it takes longer to download and uses more memory in the browser, resulting in poorer performance.  So, instead of rebuilding a score of balloons, or copying and changing the original image description, you can simply make one basic model, sans color, and reference that multiple times, with a different color and size.  It’s easier to do, and each extra balloon only increases the size of the file by a small amount, much smaller than adding dozens of duplicates.

To really take advantage of this feature takes a different way of thinking about the design.  A clever designer can even create several image components and recombine them into composites with even more variation.  Of course, it’s not always appropriate for every project, but my current project has quite a few duplicate images.

This is a feature supported by every browser with native SVG (though not every one yet allows you to reference images in external documents).  So, it’s a safe and natural feature for an SVG authoring tool to utilize in its SVG output.

Best Practice: Make liberal use of <use>.

<use> It and Lose It

Illustrator doesn’t support <use>.

Or rather, it does recognize it, and render it… but it promptly converts any instances of the <use> element to simple verbose copies of the referenced image.  I could not find any way to create an instance of <use>.

Also, when creating gradients, Illustrator seems to get overly specific about the position and dimensions (width, height) of the gradient, needlessly yoking them to a specific element at a particular location and of a particular size.  SVG allows you to define a gradient once and reuse it among several shapes, decreasing the number of gradients; Illustrator should make better use of this feature, and so should Inkscape.

This is not a tool created with the Web in mind.

Because of this quirk, my current file size is about 6 or more times what it needs to be.  Let’s see how we can work around that.

Symbolic Gestures

I spent quite a bit of time –hours, truth to tell, because I’m an Illustrator newbie– isolating individual images (trees, benches, etc.) that were used through the graphic as a whole.

When I make “symbols” (for lack of a better word), I like to find their positioning anchor –that is, the point at which they are most usefully positioned– and set that to the {0,0} point, so there are no unpleasant surprises when placing the symbol.  For most symbols, this is the centerpoint of the symbol; if I have an icon (a badge, a logo), I will position it smack dab at the point in my graphic that it should be applied, relative to other images.  For other symbols, it is one of the extremities, where it will meet up with another shape… for a tree this would be the bottom of the trunk where it sprouts from the ground, for an arrowhead it would be the base where it it attaches to a line.  I try to pick the most intuitive anchor for each symbol.

When you drag a shape to a new location, as I did for creating anchors, Illustrator converts the path or attribute values to their new coordinates, rather than simply applying a transformation.  This is something that Inkscape gets wrong (at least, last time I checked).  Nested transforms are harder for developers to work with than simple coordinates.  So, kudos to Illustrator on this one.

Each symbol is best enclosed within a group… in SVG, this is a <g> element (SVG also has a <symbol> element, but in practice, I don’t think it’s worth much).  Grouping allows the designer to collect all the constituent parts of the image together for greater portability.

When a designer works, if they are anything like me, they tweak a bit here and there, sketching out the rough shape, working on another part of the big picture, then focus on adding details.  A problem arises for a developer who has to subsequently dig into the resulting code… elements are added to the document in the order they are created, so a bunch of shapes that appear to be one symbol might be scattered throughout the document, and might even be in different layers.

Best Practice: Group early, group often.  Create graphical objects, and think about graphical / document structure.  Your developer co-workers will thank you.

Being the non-designer developer I am, my first instinct was to group the elements in a text editor, and as a clumsy first attempt to find the different elements, I used Firebug to inspect each element to find its id or unique data I could use in a text search in the text editor, but the different parts were too scattered for this to be effective; pretty quickly, I turned to Illustrator myself to do the grouping visually.

The process for converting these graphics into symbols was made much clumsier by the selection mechanism of Illustrator.  When things are grouped in Illustrator, it logically selects all the bits of that grouped image.  The problem is that it also does this with layers, as well as groups; you can “drill down” from a layer into an individual group, but when you are first trying to select a set of images that aren’t already grouped, this can be twiddly and frustrating.  Illustrator also defines far too many nested groups, decreasing their usefulness and creating markup cruft that makes later programming harder. Using the selection marquee (the draggy box), you can more easily select the constituent parts of the image, but be careful of any background elements.

Best Practice: When creating symbols, select the elements you want as part of that symbol, either with the selection marquee or with shift+click.  Right-click on the selection, and choose “Group” to group the elements, which should also group any gradients, filters, clipping paths, etc. that the shapes use; in the Layers dialog, you will see the graphics collected under a new group labeled “<group>”; double-click this, and give it a meaningful name.  (Note: you might need to right-click again and choose “Isolate Selected Group” in order to the collect the gradients and other graphical effects into the group; these are not shown in the Layers dialog, so I wasn’t sure at what point they are included in the group.)

“Let Me Tell You What I Think You Mean”

As I isolated each image, I deleted extraneous shapes that weren’t part of any symbol.  I made each symbol into its own file, just to keep them tidy.  Each symbol looked great by itself, but when I finally recomposed all the symbols together, the colors were all wrong!  A little digging revealed the problem… Illustrator changes the ids of the “paint servers” –referenceable graphical effects like gradients and filters– as you delete other shapes.  So, when I recombined the symbols into a single file, some of the gradient ids overlapped and defaulted to the first instance… which screwed up the colors.  This is a portability and maintenance nightmare.

Illustrator tried to be a little too clever here.  Like the way it unwinds <use> references and discards the <use> element, it doesn’t play well with a designer-developer roundtripping workflow.  I ran into many such cases where it discarded changes I had edited by hand.  I tried to resize the document dimensions in my text editor, but when I loaded it in Illustrator, made some changes, and saved it again, it scaled down my graphics (which I’d just explicitly scaled up) and changed the viewport to a much smaller set of dimensions.  Hey, Illustrator, if I wanted it that size, that’s the size I would have made it!  Finally, I gave up, and set the dimensions I wanted in a new file I created in Illustrator itself, and copy-pasted from one Illustrator window into the new document, which seems to have taken.  I don’t like programs which introduce inconsistency into a workflow.

What are you smirking about, Inkscape?  You pull the same kind of nonsense!

Copy-Paste Error

After all this tweaking, I ended up with more or less what I want to start with: a document with the dimensions I need, with a set of reusable symbols at the right scale.

But when I tested it out by selecting a symbol on the canvas, copying it, and pasting it in its new location, I was disappointed to find that Illustrator copied the parts of the symbol, but not the grouping… it just added the individual parts of the graphic directly in the target layer.

FAIL!

I messed around a bit more with the interface, and through luck, I stumbled on a different way of selecting the symbol.  By toggling a selection button for the group in the Layers dialog, and copying that (Ctrl/Cmd+C only… Illustrator doesn’t provide a right-click menu on items in the Layers dialog list), I could paste the group.

Best Practice: Copy and paste symbols from the Layers dialog to preserve their logical structure.

This is a far cry from having a <use> element, but I plan to apply a post-processing step to the final document, replacing duplicates with <use> references.  Luckily, Illustrator didn’t give the pasted copy a completely random id, but simply appended an incremented number to the original symbol id, so this should be fairly easy.

My next step is to turn the new document over to Michael, my long-suffering designer, and see if any of this makes sense to him, or if he will come to his senses and throttle me for imposing all this developer madness on him.

To Be Continued…

I recognize that my own inexperience with Illustrator is probably behind some of my missteps (the full extent of which I have shielded from you, dear reader).  On the other hand, a fresh pair of eyes can often spot flaws that could be eliminated where an experienced hand would simply repeat the same mistakes.

This project is far from over, and as I refine my workflow, I’ll report back what I discover.  Some of what I learn may inform future versions of SVG.  Other parts should be changes to the authoring tools.  Hopefully some of it will help help designers and developers work around issues in creating SVG with the tools they use today.

I attended Google I/O a couple weeks ago, and had a great time.  They really put the “hype” in HyperText Markup Language 5, identifying things like the Geolocation API and some of the WebApps Working Group deliverables as part of “HTML5″.  Not quite accurate, but it was a branding exercise, not a technical one.  Notably absent from the things they rolled into HTML5 during the keynote, though, was SVG… in fact, they seemed to go out of their way to avoid it.

But it’s in there.

Behind the curtains, I talked to several Googlers at the conference committed to SVG.  Brad Neuberg, a whipsmart Google engineer and all-around swell guy, is making a Javascript shim that takes SVG (referenced or inline) and renders it consistently across browsers, including Internet Explorer, using the Flash plugin.  Patrick Chanezon and Ignacio Blanco, also of Google, spoke about SVG and Canvas at JavaOne the week after.

It wasn’t a certainty that SVG integration would make it into HTML5 (rather than HTML6, etc.).  I’d been asking for it to be included for a while, but the the editor, Ian Hickson, was resistant to the idea.  At one point, he even suggested supporting some other vector graphics language, even a stripped-down custom format (which was likely a testing of the waters… in a similar vein, rather than simply integrating custom namespaces or RDFa or ITS, he reinvented his own syntax for each instead).  But ultimately, even he knew that wouldn’t fly for vector graphics.  SVG is already too well supported in browsers, in authoring tools, and as a general format for anything else to make sense.

Because it’s all about the platform.  And SVG is part of the platform.

Already, inline SVG (that is, SVG mixed into a single document with XHTML) works in all the browsers that support both XHTML and SVG (that is, all but Internet Explorer), and even worked in plain-text HTML in Internet Explorer with the Adobe plug-in almost a decade ago.  Steven Pemberton points out that that was the true innovation of XHTML, the ability to plug in new syntaxes and new functionality without having to change the core of the language or revisit parsing rules.  It has been argued that XHTML’s extensibility is superior to HTML5′s parsing rules that only work with a set vocabulary.

But the browser vendors were determined that text/html, being more common and robust than XHTML, had a market advantage, and so to fit in with that, SVG needed to work not just with XHTML, but also with text/html.  There were compromises along the way with SVG… probably chief among these are parsing issues.  Unlike XHTML, SVG was designed from the ground up for an XML syntax.  HTML uses a much more complicated parsing that defines error recovery behavior for things like missing quotes around the attribute values, case insensitivity, and non-well-formed markup, and it doesn’t support namespaces properly.  SVG in text/html has to (some say “gets to”) follow some of these rules in order to fit in.  The SVG WG was a bit reluctant to adopt these changes, out of concern that SVG might fly into tag soup, making it harder for existing authoring tools and XML-based SVG viewers, as well as generic XML processing tools.

But ultimately, we had to agree that SVG needs to conform to the platform.

So, we’ve taken a step backwards in some ways: right now, there’s pretty much no non-conforming SVG content in the wild, and the Adobe SVG viewer was fast, and had features still not found in some browsers.  But we’ve now got better error recovery, and SVG in almost all major browsers, which is more robust than a single-vendor plug-in, and is ultimately better for authors and users.  The way to use it with HTML is now better defined:

• as with HTML, for SVG in text/html, you don’t have to use quotes on your attribute values (if the value doesn’t contain spaces, etc.)
• authors don’t need to declare namespaces (in fact, this was the case with the Adobe SVG Viewer already, so not really much of a loss)
• mistakes in casing for element and attribute names will be corrected
• well-formedness errors will be recovered as best as possible, rather than halting rendering
• custom namespaces, such as round-tripping metadata inserted by authoring tools, will not be supported
• most importantly, normal valid, well-formed SVG with no custom namespaces will Just Work, whether as a standalone document or referenced as an external file, or inline in text/html or XHTML.

In fact, though HTML5 is not yet done, SVG inline in text/html already works in special experimental builds of Firefox and Opera, and should work out of the box soon.  Forward-looking authors can already use SVG in modern browsers, using XHTML, and that content will soon work when served as text/html as well. The final barrier to common use of SVG is being solved by Brad’s “SVG Web” shim, allowing SVG content to work in IE.  This will not be a perfect solution; it would be better if IE supported SVG natively without making developers jump through hoops, but that won’t happen for at least a couple years (if at all), and SVG Web at the very least will bridge the gap.  I’ve seen it run, and it’s pretty impressive already.

That SVG has had to bend in the wind gives the SVG language a unique opportunity to innovate.  If the syntax is already going to need an update in existing browsers and authoring tools, we can reexamine some old assumptions and past missteps, and extend SVG to be better integrated with HTML and CSS and existing scripting practices.  And even more importantly, we can examine use cases and make SVG better suited for what authors need to do.

Why is HTML5 a powerful enough platform that Google throws it’s weight behind it, despite the inaccurate and ungainly name?  Is it the error-correcting parsing?  No, that’s a good feature, even if the need for it is unfortunate, but it’s unclear that this is better than XHTML.  Is it the new features like the <video> and <audio> elements, which allow it to compete with the most common use of Flash?  No, that capability has been possible using XHTML and SMIL for years, and is even part of SVG Tiny 1.2 (N.B.: HTML’s script interfaces are simpler and better than SMIL’s, but its lack of synchronization or timing containers is a big step back).  Is it the new WebApp-centric user interface focus?  No, we would probably be better served by a language designed for making UIs (like XUL).

So, what is the true power of HTML5?  Coordination.  Getting all the browser vendors to standardize on a common set of features.  HTML5 is not a technical achievement, it’s a social movement.  It’s an instantiation of the Open Web in the form of several specifications across several groups, and implemented fairly uniformly across all major browsers and platforms.  This is largely in response to user demands to the browser vendors.  They are tired of the special-casing and workarounds that make their lives and jobs harder and less satisfying, that make users struggle… they want a consistent platform, one without script libraries or shims or plug-ins or arcane rules.  And the browsers realize this, and know that a rising tide raises all ships.

My personal advice to vendors who have excellent authoring tools, but who want to also control the runtime environment?  The Web has moved on from vendor lock-in and black-box plug-ins.  In a world where there is coordination between multiple vendors to deliver and support a central set of technologies, where everyone is unifying on a standard Open Web platform, from Apple to Google to Mozilla to Nokia to Palm to Opera to Vodafone.  Nobody wants the hassle of being the only one to maintain the platform, but they all want the ability to change it without going though the gatekeeper of a single vendor.

It’s all platform games, and if you want to play, you have to jump to the next platform.  Google knows this… they are hosting the next SVG Open, and are aggressively pushing the whole platform.  Looks like a fun year ahead!

So, I don’t really pay much attention to my blog, or my site stats, or any of that… probably not nearly as much as I should, given how effective a medium blogs are at promoting ideas in the Web Standards profession.  I tend to write quite a lot, but most of it is emails to various technical mailing lists, especially W3C lists.  I should probably pay more attention to getting ideas out into a broader public sphere, with more diverse comments and feedback, like you can do with a blog.

But not this blog… not right now.  Because this blog is invisible.  If I recall correctly, I had a PageRank of 6, which seems to be moderately respectable.  But since my blog was hacked (maybe because it had a PageRank of 6), no amount of PageRank will help, because Google has cut me off.  So, as I mentioned on my last post, I did all the voodoo, adjusted the bones just so, and asked Google pretty-please won’t they reindex my site.  They replied that they will think about it, in a few weeks (just slightly passive-aggressive in a way only the popular kid can be).  I wonder if my PageRank will emerge intact?

But on the up side, I took the opportunity to clean out my virtual attic.  I took down old content and databases and experimental installations of software, wiped out old user accounts and email addresses, and generally made it easier for me to manage everything.  Installing the latest version of WordPress also gave me the chance to reorganize the sidebar a bit, adding my Twitter feed and removing dead blogroll links (though I need to add some new ones).

I should also try to figure out a way to finally expose an index of all the hundreds of SVG files I have hidden in the back alleys of my site.  Some of them are just experiments, some are examples of best practice, some are fairly cool and elaborate, some are just conformance tests.  I’ve hesitated because some of them are also rather crappy code that was written for the Adobe SVG Viewer, and either doesn’t have a namespace declaration (so it won’t work in modern browsers), or it uses some feature not supported in most browsers.  I’ve now put up an empty placeholder page, just to lay the groundwork.

I’ve also entertained the notion of running an index of my posts to public W3C lists, but out of context, it probably wouldn’t mean anything, and wouldn’t offer more than you could get by just searching the lists manually.  Maybe a weekly summary would be better?  Or maybe no mention of it at all would be most preferable… I think a certain amount of silence from me would do me and the people around me a world of good.

Maybe getting blocked by Google is a good thing after all…

Wow.  After a ridiculously long time in preparation, with political battles along the way, and a long slog of making tests and maintaining older versions of the spec, as well as working on supporting specs like Element Traversal and DOM3 Events, SVG Tiny 1.2 is finally a W3C Recommendation.  Whew!

I say “finally” for a few reasons:

1. It’s taken too long between revisions of the spec, demoralizing the SVG community and losing market interest
2. The spec has been 3 months away from being finalized since I first joined the SVG WG in January of 2006, and again when I joined the W3C staff in July of 2007
3. Cutting edge for its time, SVG no longer has the lead over Flash for mobile devices in terms of features
4. Mobile devices are now more powerful than when the spec was first started, so some features that were cut out to fit on older devices now could work just fine
5. SVG Tiny 1.2 has been already had multiple implementations for mobile phones and embedded devices for something like 3 years

After 3 years in the making, SVG 1.0 was published as a Recommendation on 04 September 2001.  SVG Full 1.1, was published 14 January 2003, and the 1.1 mobile profiles, SVG Mobile and SVG Tiny, were published the same day, 14 January 2003.  The SVG 1.2 family started way back in 15 November 2002, following quickly on the heels of earlier specs, and the first draft of what would become SVG Tiny 1.2 dates back to 09 December 2003.  But various detractors of SVG threw a monkey wrench into the gears of SVG, thinking that it went too far in the direction of providing a Web application framework (one of the more common uses of SVG), and wanted to promote HTML and CSS for the same purpose.  Why not use both together, which seemed like an obvious solution?  Maybe because none of the major browser vendors supported SVG natively, and they did support HTML and CSS.  So, in a hail of hostile comments, the SVG WG hunkered down to improve the specification and the test suite, to meet higher standards than any previous W3C browser-centric specification had been held to.  Fair enough… it’s a new era, with more major browsers than ever before, and a greater need for interoperability.

So, that’s the bad news… what’s the good news?

Well, first, SVG is finally a Recommendation, and is broadly supported on mobile devices.  The SVG WG is already working on several specifications (we’re calling them modules) to build on existing SVG specifications (SVG Tiny 1.2 or SVG 1.1) and extend the feature set, to make it easier to author and to do cool stuff (as I’ve mentioned before).  The SVG WG is working with the HTML WG (some of the same folks who wanted to reanimate HTML… they achieved their objective) to make it easy to use SVG inline in HTML (that’s text/html… it already works in  XHTML), which should allow folks to make some pretty slick content.  SVG 1.1 is widely implemented in toolkits and authoring tools (Inkscape, Illustrator, and others), and works fairly interoperably (though not perfectly so, yet) in Firefox, Opera, Safari, and Chrome… all the major browsers except Internet Explorer (so far).  And Mozilla has hired a dedicated developer, the mighty jwatt, to improve their SVG support and to participate in the SVG WG.

The SVG WG has taken to heart the lessons of the past (most of us are second generation SVG WG members), and have higher standards for producing good specs and comprehensive test suites, and are excited about polishing the edges of SVG so that it works well with HTML, CSS, and the WebApps WG specs (like XHR, Element Traversal, Selectors API, Widgets, etc.).  We know that the future is in mixed-namespace content (what I call “blendups”, SVG+HTML+CSS+JS, all working together, and with shared interactivity).

All in all, though the path to this point has been too long, I think the road ahead for SVG, and Open Web development in general, has turned a corner.  Now we just need to keep meeting those milestones.