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.