SVG in HTML

From SVG

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


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?
     <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>

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: 

     <svg>
        <circle/>

  </svg>

Unclosed element in SVG: 

     <svg>
        <circle cx='50' cy='25' r='20'>
     </svg>
  • 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
     <svg:svg xmlns:svg="http://www.w3.org/2000/svg">
        <svg:circle cx='50' cy='25' r='20'/>
     </svg:svg>
  • 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
     <svg xmlns="http://www.w3.org/2000/svg">
        <circle cx='50' cy='25' r='20'/>
     </svg>
  • Inline SVG elements in no namespace
    • moderate ease of authoring
    • SVG fragment will not work in most current SVG UAs as is
     <svg>
        <circle cx='50' cy='25' r='20'/>
     </svg>
  • 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
     <svg:circle cx='50' cy='25' r='20'/>
  • 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
     <circle cx='50' cy='25' r='20'/>

A green circle: <script type="image/svg+xml"> <circle r="50" cx="50" cy="50" fill="green"/> </script>

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
Retrieved from "https://www.w3.org/Graphics/SVG/WG/wiki/index.php?title=SVG_in_HTML&oldid=1176"