Issues and Considerations with SVG in HTML inline

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:

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

Prior Explorations & Related Reading

To Do

Add links to email archive references