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!