View source for SVG in HTML

[[Category:Archive]]
This page is an archive of the previous Group's wiki from http://www.w3.org/Graphics/SVG/Group/wiki.

__NOTOC__
= Issues and Considerations with SVG in HTML inline =

== 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:

   <div>
      <svg>
         <circle/>
      </div>
   </svg>

Unclosed element in SVG:

   <div>
      <svg>
         <circle cx='50' cy='25' r='20'>
      </svg>
   </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>

== To Do ==

* Add links to email archive references