Chris Jay: Vector Graphics should belong to the web

There have always been two competing SVG visions.

One camp sees SVG as a stand-alone XML format for graphical applications, such as graphical design tools or mobile phone user interfaces.

The other camp sees SVG as belonging to the web - an extension to HTML, and a way for web designers to add exciting new features to their pages. Sitting in this camp are the browser makers (and probably most of Silicon Valley, when they think about it).

Of course, there is a spectrum of viewpoints between the two - but the W3C seems dominated by the stand-alone camp, who have seemingly neglected interoperability with HTML, CSS and current browsers.

This is betting against the internet. The browser is the new platform, and HTML, CSS and javascript are the basic formats of choice. SVG must fit into that picture.

Silverlight and Flash are not the answer

Microsoft and Adobe have proprietary vector graphics packages, using plug-ins (in fact, both also handle streaming video and audio). Adobe's Flash has a huge installed base, and both come with great design tools for creating compelling content.

But they also have weaknesses. They follow proprietary standards, they are inaccessible (especially in their binary formats), they overlap with HTML functionality, they're not propertly part of the DOM, and they don't have CSS support.

Therefore both Silverlight and Flash firmly belong to the stand-alone camp, not the "part of the web" camp.

SVG should be an extension to HTML, CSS and the DOM

Another way of saying "part of the web" is to say "an extension to HTML, CSS and the DOM".

That is, SVG should start with the existing web - our current browsers and websites - and provide additional elements, attributes, styles, and scripting power, to support vector graphics.

In this spirit, I've listed ten principles that I think SVG should follow. Browser makers can follow these principles while maintaining compliance with SVG 1.1.

For the examples, I've set XHTML as the default namespace, and I've linked "svg:" to the SVG namespace

1. No foreignobject required for HTML

SVG has a <foreignobject> element, which you're meant to use for inline XHTML. Surely this isn't necessary - so long as elements have the right namespace, you should be able to mix them any way you want. Browsers should allow XHTML inside SVG, without <foreignobject>, e.g.
<svg:svg>
<svg:rect x="0" y="0" width="100px" height="100px"/>
<p>Hello</p>
</svg:svg>

The HTML is positioned according to its parent, i.e. the <svg> element - see point 5 below.

2. Apply SVG layout to HTML

HTML uses the box model for layout - everything is aligned to, and contained within, vertical and horizontal boxes.

SVG allows transformations for scaling, rotating and shearing coordinates. This is much more powerful than the box model, and might seem to be inconsistent - but actually, it's not! You can construct twisted HTML boxes, following the coordinate axes.

So, browsers should allow things like:
<p svg:transform="rotate(45)">Hello World</p>

3. Apply SVG fills, strokes, gradients, filters, patterns, and painting to HTML

You should be able to apply all the great SVG effects to plain old HTML. See the example below for an HTML paragraph that has been filled with a red to yellow gradient!

4. Apply SVG CSS to HTML

If you look at the example above, the svg "fill" attribute carries out a similar role to the HTML "background-color" style. I don't see this as an issue - whenever present, it would take priority over CSS 2.1 styles. Similarly, SVG "strokes" would take priority over HTML "border" styles.

This would also apply to external CSS files, as the example below shows:
p {stroke-width: 2px; fill-opacity: 0.5;}

Not only do SVG styles overlap somewhat with HTML ones, but they use different conventions for units, too. In HTML, CSS values must have a unit; in SVG, they don't have to. Fortunately, the SVG "px" unit works the same as having no units, so browsers could define "px" as the default unit.

5. Apply HTML CSS to SVG

The SVG <svg> element could follow the box model, allowing floating and automatic re-flow on page re-sizing. For example,

6. Allow HTML inside SVG shapes

A common complaint with HTML is that everything appears boxed - you can't, for example, put a paragraph inside a circle. Well, with SVG you can - see below!
<svg:circle cx="100" cy="100" r="50">
<p>Hello World</p>
</svg:circle>

The browser should wrap the text inside the circle element. Standard CSS styles like margin and text should still be valid - for example, left-aligned text.

What this means is that instead of plain old <div>, you can use <rect>, <circle>, <ellipse>, and <polygon> too. So long as the contents are pure HTML - no SVG, that would break the spec - this would help enormously.

7. Use HTML for text, not SVG

Unlike SVG, HTML was specifically designed for text. SVG 1.1 doesn't have semantic text elements, like <p> for paragraph or <h1> for header or <ul> for bullet points. It doesn't even allow text wrapping!

Once you've allowed SVG effects to be applied to HTML (points 2, 3 and 4 above), the only advantage to using SVG text is the <textpath> element - so let's allow that one too, as below!

Imagine the power of this - you could have whole paragraphs, even <div> elements, following bendy paths! Again, this isn't inconsistent with the HTML box model - see point 2 above.

The SVG <text> element is then totally redundant. You can still keep it in browsers, for backwards compatibility, but no one need use it.

8. Allow HTML animation

SVG 1.1 includes elements from SMIL, allowing animation. This always struck me as slightly bizarre - why not just keep them in the SMIL spec, and reference them?

Anyway, in a combined SVG / HTML document you should be able to apply animation to HTML elements too:
<svg:circle cx="100" cy="100" r="50">
<p id="p1" fill-opacity="1">Hello World</p>
</svg:circle>
<svg:animate xlink:href="#p1" attributeName="fill-opacity" attributeType="XML"
begin="0s" dur="9s" fill="freeze" from="1.0" to="0.0" />
You could also animate the paragraph's position, by moving the containing circle around.

9. Browser-based SVG design tools

There's a real lack of proper SVG design tools. Inkscape hasn't even reached version 1.0 yet, and it's holding back designers from using SVG.

Rather than creating a client SVG design tool, why not just use the browser? Anyone could log on using Opera, Firefox, or WebKit, and create, edit, save, search, collaborate, and publish their designs. You can imagine it as part of the Google Apps suite. All the sophisticated rendering would be done by the browser - the editing is just javascript!

10. Keep the dream going

The SVG community are not in good spirits. There is discontent at the W3C, who maintain the standard, especially from Mozilla and Apple who feel left out in favour of mobile phone vendors more interested in closed garden solutions. Adobe have dropped support for their plug-in, which was the best way to get SVG support in Internet Explorer. Mozilla have dropped several SVG elements from their forthcoming Firefox 3 browser, stating competing priorities. And Microsoft have announced their own proprietary, competing solution - Silverlight - to great fanfare.

And yet, the dream remains tantalisingly close - in 9 months time, probably 20% of all desktop browsers, most smart phones, and many other devices (e.g. the Wii) will have pretty good SVG support. Can the slow, steady, and scattered progress of SVG overcome the might of Microsoft and Adobe?

You bet it can. We just have to ditch stand-alone SVG, and ride the internet.

Chris Jay

Sunday, June 03, 2007

Vector Graphics should belong to the web