View source

From SVG

You do not have permission to do that, for the following reasons:

• The action you have requested is limited to users in one of the groups Sysops, svgEditors.
• You must confirm your e-mail address before editing pages. Please set and validate your e-mail address through your user preferences.

You can view and copy the source of this page:

Add SVG WG proposal details here.... Draft Notes ==Proposals== [[ext element]] ==Use Cases and Requirements== * SVG should remain XML when inline in HTML. * Should be able to take a conforming SVG document and paste its contents into an HTML document and have it be the same DOM. (That is, it should be possible for authors to create an SVG document in Inkscape, take the contents of the file, and include it directly in the HTML without having to munge its syntax to get it to work.). This includes script content. * Should be able to take a conforming HTML document and copy the SVG fragment from it and paste it into a new file and that would be a conforming SVG document. (That is, it should be possible for authors to, when they come across an SVG-in-HTML fragment, copy and paste that source and open it up in Inkscape to edit.) * Should be able to provide some sort of fallback mechanism for the SVG-in-HTML so that UAs that don’t know how to handle these SVG fragments will display the fallback. * Should allow for unrestricted growth of the SVG language by the SVG specifications (though those specifications should also take into account the idea that SVG will, going forward, be used more commonly in concert with HTML). This means that there would be no "white list" of allowed SVG elements in HTML. It also means that the SVG spec should be more careful about element and attribute names going forward. * Should allow for SVG Fonts to be included in HTML, and ideally to be usable in HTML text. * Should attempt to avoid breaking existing text/html pages. However, this must be balanced with the need for a clean, sustainable architecture. * Should specify a tolerant error handling model, for the following reason: Authors often blindly copy-paste markup snippets from other pages and only test in a subset of UAs, and may retain these snippets even if they have absolutely no effect in the tested UA. So if some construct requires strict error handling in new UAs, but is parsed tolerantly in older UAs, in practice there will be content that is broken in the newer UAs, creating incentives for them to add tolerant error handling. ==Fallback Mecahnism== See [[Ext element]]. ==Use Cases and Requirements Discussion== ''from Erik'' * SVG must preserve as big parts of its XML syntax as possible when inline in HTML. ** There are several exceptions to this requirement: *** Doctype and XML PI:s are ignored *** Character encoding is taken from the main document *** Unquoted attribute values? Would need separate attribute value parsing definition in HTML5. (Vote: Allow or Disallow) **** Schepers: at the present, I do not think unquoted attribute values are a wise idea (this could change if there is a new XML parser) *** The "svg" start tag may skip declaring the svg and xlink namespaces, but if xmlns is provided it must be used instead (Vote: Allow or Disallow) *** Schepers: I'm not strongly against the namespace declaration, but would think it would be a good way to trigger the SVG parsing *** Entity references can only come from the main document *** Allow non-CDATA-escaped script element content? (Vote: Allow or Disallow) **** Schepers: This is already allowed in SVG, it's only needed when the < or & operators are used *** In particular this means: **** Element and attribute names are case-sensitive, wrong element name casing should lead to the HTML parser inserting an element with the casing preserved for the tagname in the current element's namespace **** Namespaces in XML must apply to svg fragments **** "xml:" prefixed attributes must work the same as in SVG **** Attributes and elements can be prefixed **** If elements are misnested then the svg fragment must be made invisible, (and all elements must be made into legacy elements in the html namespace?) **** <svg:script xlink:href="foo.js"> elements will execute in new UA:s even if the svg content is supposed to be invisible **** SVG elements must never be automatically closed by the HTML parser, instead mark the content as invisible and exit the "in foreign content mode" **** There must always be an svg root element, un-svg-parented circle elements for example should end up in the HTML namespace *** The main extensibility-point from the SVG container is the foreignObject element *** Inline fallback content must be provided here if at all ''from Doug'' * Should be able to take a conforming SVG document and paste its contents into an HTML document and have it render. (That is, it should be possible for authors to create an SVG document in Inkscape, take the contents of the file, and include it directly in the HTML without having to munge its syntax to get it to work.) * Should be able to take a conforming HTML document and copy the SVG fragment from it and paste it into a new file and that would be a conforming SVG document. (That is, it should be possible for authors to, when they come across an SVG-in-HTML fragment, copy and paste that source and open it up in Inkscape to edit.) * Should be able to provide some sort of fallback mechanism for the SVG-in-HTML so that UAs that don’t know how to handle these SVG fragments will display the fallback. * Should allow for unrestricted growth of the SVG language by the SVG specifications (though those specifications should also take into account the idea that SVG will, going forward, be used more commonly in concert with HTML). This means that there would be no "white list" of allowed SVG elements in HTML. It also means that the SVG spec should be more careful about element and attribute names going forward. * Should allow for SVG Fonts to be included in HTML, and ideally to be usable in HTML text. * Should allow for the creation of scripted content that works identically for inline SVG and standalone SVG (though there may be certain limitations placed on the script author). This may entail SVG elements be in the SVG namespace in the DOM. * Should have a clean model for how the various DOM interfaces work together. ''from Maciej'' * Existing pages must not break (to a significant extent), even if they are currently using crazy broken syntax. * Any constructs added inline to text/html must specify a tolerant error handling model, for the following reasons: **Authors often blindly copy-paste markup snippets from other pages and only test in a subset of UAs, and may retain these snippets even if they have absolutely no effect in the tested UA. So if some construct requires draconian error handling in new UAs, but is parsed tolerantly in older UAs, in practice there will be content that is broken in the newer UAs, creating incentives for them to add tolerant error handling. **Adding any draconian error handling to HTML to support SVG misses the point of using text/html, because why not just use application/xhtml+xml in that case? Currently all browsers that support SVG also support proper XHTML. I do not see a significant use case for mixed content where half of it is parsed with a tolerant model, and half draconian, as this gives you the worst of both worlds. ==Issues and Considerations with SVG in HTML inline (older notes)== This is a first draft to summarize some issues that need to be solved for SVG in text/html. It's broken down into bulleted lists for future expansion into prose. This is very incomplete, and any additions are welcome. The first draft was the result of brainstorming by the SVG WG, and was composed with an attempt not to solve issues, but to raise them in an impartial analysis; no undue significance should be placed on categorizing options and points as "pros and cons", as that is only informed opinion. ===Compatibility=== * it seems to be generally desired that SVG content act and use same syntax for both inline and standalone content ** easier to generate ** easier to copy-paste ** preserves SVG content and processing model * same syntax in standalone, HTML, and XHTML? * another point of view? ===Namespaces=== * what are the costs of XML Namespaces in SVG-in-HTML? * does "<svg " automatically open the SVG namespace, and xlink namespace? * how should xlink:href be handled * xml:id, xml events, xml:lang, xml:space * xlink as XML NS, or as "magic prefix"? ** Adobe SVG Viewer uses "magic prefix"; FF, Opera, and Safari require XML NS declaration * lots of content (especially from Inkscape) uses multiple NS declarations/prefixes ** ignore unknown attributes? * should arbitrary namespaces work? <div> <svg xmlns="http://www.w3.org/2000/svg" xmlns:foo="http://www.example.com/fooML" > <circle cx='50' cy='25' r='20' foo:drag='true'/> </svg> </div> ====xlink:href vs. href==== * authoring/copy-paste problem? * get/setAttributeNS problems for newbies * legacy UA support issue * legacy content solved by allowing both (messy, but workable) ===Parsing issues=== * How to treat misnesting in SVG? What parser to use for SVG in HTML? ====XML parser==== =====Pros:===== * Already used for SVG, so small cost of implementation *** Properly supports namespacing * Checks XML wellformedness and other criteria =====Cons:===== * It's another parser * Possible setup cost * Needs to find closing <svg> tag before handing content off to be parsed? ====HTML5 parser==== =====Pros:===== * No need to switch to another parser * Liberal in what content it allows * Creates tree immediately? (Does it need to know about the closing <svg> tag before creating elements?) * effect on incremental rendering? =====Cons:===== * Namespaces not supported * Liberal in what content it allows, * May lead to svg content that won't work in anything but HTML parsers * Consequence of chosing the HTML5 parser: ** Attribute value escaping (' and ") * How to handle wellformedness errors in SVG fragments ** Empty svg image (If can't be parsed by XMLparser don't display anything) ** "Fixed" by HTML parser (display something, which will look broken) Overlapping elements: &lt;div> <svg> <circle/> &lt;/div> </svg> Unclosed element in SVG: &lt;div> <svg> <circle cx='50' cy='25' r='20'> </svg> &lt;/div> * Other issues ** Should strict case-sensitivity in element names and attribute names and values be used as as per the current SVG specification. ** Character entity references. ** CDATA sections to escape Javascript. ===Root element=== * What is the minimal allowed syntax for embedding svg content in HTML ** need for "svg" prefix? ** Inline SVG elements with namespace declaration with namespace prefix *** most strict *** most verbose *** least easy to author *** SVG fragment should work in most SVG UAs as is <div> <svg:svg xmlns:svg="http://www.w3.org/2000/svg"> <svg:circle cx='50' cy='25' r='20'/> </svg:svg> </div> * Inline SVG elements with namespace declaration ** moderately strict ** moderately verbose ** relatively easy to author ** default output for most SVG authoring tools ** SVG fragment will definitely work in SVG UAs as is <div> <svg xmlns="http://www.w3.org/2000/svg"> <circle cx='50' cy='25' r='20'/> </svg> </div> * Inline SVG elements in no namespace ** moderate ease of authoring ** SVG fragment will not work in most current SVG UAs as is <div> <svg> <circle cx='50' cy='25' r='20'/> </svg> </div> * Inline SVG elements without an svg root/(with an implicit root), with namespace prefix ** not strict ** not verbose ** may need to insert implicit root, may make DOM parent-child unclear ** ease of authoring for simple use cases ** doesn't require any real namespacing ("magic prefix") ** no viewport/coordinate system ** intrinsic size would be bounding box of all elements *** still need <g> root to group shapes, or the shapes will each have their own viewport ** might be authored by accident, might be nice to allow recovery <div> <svg:circle cx='50' cy='25' r='20'/> </div> * Inline SVG elements without an svg root/(with an implicit root), without namespace prefix ** not strict ** penultimately least verbose ** no viewport/coordinate system ** challenges to parsing? ** element name collision (<title>, <textArea>) ** might be authored by accident, might be nice to allow recovery <div> <circle cx='50' cy='25' r='20'/> </div> * Inline SVG elements with a <script> element as the root ** http://intertwingly.net/blog/2007/10/18/SVG-in-HTML-Momentum-Building <p> A green circle: <script type="image/svg+xml"> <circle r="50" cx="50" cy="50" fill="green"/> </script> </p> ===Content Model=== * Where is SVG content legal/allowed? ** allowed everywhere, but only rendered certain places? *** if not rendered, should still be in the DOM? ** allowed/rendered anywhere <object>, <iframe>, <embed>, and <img> are? ===Referencing with <use>, <tref>, gradients, filters, fonts, etc.=== * Can SVG content in one inline SVG fragment be able to reference content in another inline SVG fragment in the same document? ** what if it's not rendered, but is in DOM? * external references? * <tref> referencing HTML textual element content? ===CSS Issues=== * CSS style properies for width/height on referenced content vs. inline content behaves differently? <svg width="100" height="100" style="width:50em; height:50em"> <circle cx='50' cy='25' r='20'/> </svg> ===Prior Explorations & Related Reading=== * http://intertwingly.net/blog/2006/12/05/HOWTO-Embed-MathML-and-SVG-into-HTML4 * http://intertwingly.net/blog/2006/12/18/application-xhtml * http://intertwingly.net/blog/2007/05/04/Inline-SVG-in-MSIE * http://intertwingly.net/blog/2007/08/02/HTML5-and-Distributed-Extensibility * http://intertwingly.net/blog/2007/09/11/SVG-on-IE-via-Silverlight-Revisited * http://intertwingly.net/blog/2007/10/18/SVG-in-HTML-Momentum-Building ===To Do=== * Add links to email archive references

Return to SVG in text-html.