RE: SVG in HTML proposal

The 8 requirements this proposal posits are functional things that make sense to authors. If HTML5 is to be true to its promise to provide the ability to create client-side applications running in the web browser, standardized vector graphics are a must. Having SVG coexist within HTML is a must. Is there any way around that fundamental conclusion? Design principles be hanged (they are like the music on the bus);  let's talk about where the bus is heading. 
 
Thanks Erik and group! It looks quite compelling. 
David

________________________________

From: public-html-request@w3.org on behalf of Erik Dahlström
Sent: Mon 7/14/2008 4:05 AM
To: public-html@w3.org
Cc: www-svg@w3.org
Subject: SVG in HTML proposal



Hello HTML WG,

The SVG WG is happy to announce the first draft proposal for how to handle SVG in HTML (see attachment).

The abstract of the proposal is duplicated in text format here:

The SVG language was created to meet developer and user needs for full-featured, open, and intuitive vector-graphics functionality for the Web. It was developed over time in response to community and vendor needs. From its inception, it was intended to integrate with and extend other prominent open Web platform technologies, such as X/HTML, CSS, and Javascript. It provides animation and interactivity in both declarative and scripted modes, filter effects, gradients, fonts, and many other features.

However, due to delayed implementation by major browsers and reliance on limited plugins, integration with HTML, particularly with inline SVG, was incomplete; consequently, many features for combining the two formats were underspecified or inconsistently implemented. With the increased native uptake of the SVG technology in major browsers, and the renewed development of HTML in browsers, a new opportunity has arisen for integration.

SVG is an XML language by design, and therefore has certain abilities and constraints at the syntactic level that are dissimilar to those of text/html (but consistent with XHTML); therefore, to work correctly, with the full range of features, SVG must follow the syntactic rules with which it was designed, in both HTML and XHTML. This consistency will aid developers, who will not need to learn two separate sets of rules for the syntax and feature sets. It will maintain compatibility with existing SVG viewers, and continue to permit round-tripping in SVG authoring tools such as Inkscape, Adobe Illustrator, and CorelDraw, which rely on the XML format.

This document is a proposal for integrating SVG in both the text and XML serializations of HTML5. This proposal follows the model that works today in every major browser that supports XHTML (Firefox, Opera, and Safari), all of which also support SVG natively. It also works to a lesser extent in Internet Explorer, with the use of an SVG plugin (and a small bit of extra code). The SVG WG believes that this satisfies the spirit and the letter of the HTML5 Design Principles, particularly in the aspects of compatibility.

This proposal is fairly complete, but it does have some minor gaps yet to be filled in, and so more detail may follow. However the SVG WG believes that it meets and exceeds the basic requirements laid out by the editor for the HTML5 specification. The SVG WG is very interested in taking community feedback into account. Please send comments or questions to www-svg@w3.org, the public SVG email list.

Note that this is not a formally published document, nor is it on the Recommendation Track. It is merely an inter-group proposal. This document is a work in progress, and may change due to feedback.

On behalf of the SVG Working Group
/Erik

--
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Tuesday, 15 July 2008 01:02:15 UTC