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!

<svg:defs>
<svg:linearGradient id="MyGradient">
<svg:stop offset="5%" stop-color="#F60" />
<svg:stop offset="95%" stop-color="#FF6" />
</svg:linearGradient>
</svg:defs>
<p svg:fill="url(#MyGradient)">Hello World</p>

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,

<svg:svg>
<svg:circle cx="100" cy="100" r="50"/>
</svg:svg>
<svg:svg style="float:left">
<svg:circle cx="100" cy="100" r="50"/>
</svg:svg>
represents two circles that float next to each other, just as jpgs would on the page. Any HTML CSS style, including layout styles, can apply to the <svg> elements.

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!

<svg:defs>
<svg:path id="MyPath"
d="M 100 200 C 200 100 300 0 400 100 C 500 200 600 300 700 200 C 800 100 900 100 900 100" />
</svg:defs>
<svg:textPath xlink:href="#MyPath">
<p>We go up, then we go down, then up again</p> </svg:textPath>

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.

HTML audio and video

HTML 5 will introduce new <audio> and <video> elements, for including these objects on a web page in a simple, standard way. Just as Netscape originally became successful due in part to the new <img> element, you can expect browser makers to quickly implement and take advantage of sound and video.

Currently, sound and video is only available using the general purpose <object> element and various non-standard techniques for each plug-in (QuickTime, Silverlight, Flash, etc).

The new elements have several benefits:

• accessible - to search crawlers, the visually impaired, etc
• standard API - consistent DOM, javascript, and HTML elements & attributes
• standard user interface - for play, pause, etc
• integrated with the web page - part of the DOM, controllable by javascript for play, pause, volume, etcclear scope - just for video and audio, not for e.g. vector graphics

Possible uses of them include:

• Web page control of play, pause, fast forward, etc
• Web training videos with multiple choice tests on completion
• Video SVG filters (e.g. guassian blurs)
• Synchronized subtitles and sign language

Revealingly, both Flash and Silverlight don't neatly fit into this picture. They don't only enable video - they also handle vector graphics and html-like text. I suppose you could use the <video> element for Flash videos, and the <object> element for Flash graphics and text. But ideally you'd instead use html for text, and an element like <svg> or <vml> for vector graphics, in order to maintain the benefits above.

Once you've got normal html, <video>, <audio>, and <svg>, is every type of multimedia covered? No - there's still a need for interactive gaming user interfaces and 3D, for a start. But you're much further, and there's always the <object> element for missing pieces.

Voice Browsing

There's a famous story about the Microsoft developers perfecting voice recognition for Windows - it worked great until one of them visited a friend's video website of someone shouting "Start - Run - Format C - OK".

It's a great tale, but it's also a fundamental security issue that could derail most attempts at voice control of the client. The microphone should only be available to the application with focus (and not available for OS commands), and for privacy reasons, applications should always make it clear when they're listening and what they're likely to do with the data.

These rules are pretty restrictive - but they fit very neatly onto the web!

The vocal web

The web was designed with accessibility in mind - so that people with visual impairment could still access the web, by using voice browsers that read pages out load. There are even rarely used CSS styles for controlling vocal pitch, volume and tone.

But the web isn't just for people to read data. What's missing is a standard way to write data using speech - especially filling out the standard HTML <input> and <textarea> elements.

If this were possible, developers could create the following:

• Mobile phone search engines - just talk to Google!
• Dictated web email, blogs, or private notes
• Full use of most applications - e.g. Amazon or eBay - for the visually impaired

Vocal HTML

Following the security rules above, any website could be speech-enabled in three steps:

• Users adjust their browser settings to allow speech input (this could be a default on mobile phones)
• Developers prompt speech by styling input boxes with CSS 2.1 "cue-before" and "cue-after" styles
• Browsers vocally prompt form submission when they reach a submit element.

That's it!

There are two methods to do speech recognition:

• Client-side: A browser plug-in converts speech to text, places the text in the relevant HTML element, then submits the form on request.
• Server-side: For POSTed forms, browsers simply attach an mp3 or audio file for translation by the server

Despite the history, still lots of opportunity

Voice recognition has been talked about for ages, but it's still a niche - many people probably still think it's a distant dream.

But that will change, especially with the rise of the internet and mobile phones. And when it does, it won't only be the visually impaired that gains; it will be anyone accessing the internet without a good keyboard.