Using SVG elements directly in HTML

Hi,

Here is a summary of one of some of the ideas around integrating HTML 
elements into SVG that we plan to discuss at the F2F today.


Motivation:
-----------

* Some elements, semantically and practically just shouldn't need to be 
wrapped in <foreignObject>, e.g. <template>

* There are other elements with authors frequently want to use in SVG 
such as <p>, <button>, <iframe>, <video>, and <canvas> for which using 
<foreignObject> is sub-optimal because:
- For <iframe> requiring <foreignObject> makes it necessary to manage 
two viewports since <foreignObject> doesn't shrinkwrap its contents.
Hence, embedding another SVG image looks like this:

  <foreignObject x="50" y="50" width="100" height="100">
    <iframe width="100" height="100" src="svg.svg"
      xmlns="http://www.w3.org/1999/xhtml"></iframe>
  </foreignObject>

But it would be nice to just write:

  <iframe x="50" y="50" width="100" height="100" src="svg.svg"/>

- <foreignObject> is long and ugly to type
- For standalone SVG documents, requiring a namespace on children of 
<foreignObject> is a pain (this SVGWG member has to look up the 
namespace of SVG/XHTML every time—largely to remember if there is a 
slash at the end or not)
- For use-cases where a lot of HTML content is used (e.g. map files made 
up of a matrix of <iframe> map tiles), the overhead introduced by 
<foreignObject> may be significant, although this is a lesser concern.


Some technical background:
--------------------------

For the SVG-embedded-in-HTML case the following fragment:

   <!doctype html>
   <svg>
   <span id="s"></span>
   <div id="i"></div>

The <span> and <div> end up as siblings of the <svg>.

See: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3276

This is because the HTML parser breaks out of foreign content mode when 
it sees certain tags. See the rules for parsing tokens in foreign 
content, particularly about the 6th item there.

This was done because several pages were found that erroneously include 
a random unclosed <svg> tag somewhere towards the start of the document. 
If the content were processed in foreign content mode, none of the 
remainder of the page would render.

Apparently the set of tags listed in the spec corresponds to actual 
elements found following the <svg> tag although it does seem quite large.


Discussion so far:
------------------

* The wikipage from the last F2F summarises the issues up to that point[1]
* There are minutes from the subsequent discussion[2]
* Since then a few of us got feedback from Hixie about some of these ideas


Possible approaches:
--------------------

We have discussed a number of possible approaches to this.


Common to all approaches

Allowing <template> in SVG should be straightforward. We both can and 
probably should do this. If any changes to HTML are required we should 
just file bugs on the whatwg spec: https://whatwg.org/newbug. We may 
also need to adjust the SVG parser to allow this in the standalone SVG case.

(“may” because exactly what is required here will depend on the approach 
we choose from below as well as what we decide about namespaces.)

If we're to make any of the HTML elements that currently close the <svg> 
element to stop doing that, then we have to think about compatibility 
for those pages. I'm going to pick up this issue below, however, since 
first it makes sense to outline the possible scenarios.


<div> approach

In this approach, we only allow <div> to appear by itself in SVG (in 
addition, of course, to <template> as above).

The <iframe> example from before becomes:

   <div style="x: 50; y: 50"><iframe width="100" height="100" 
src="svg.svg"></iframe></div>



Whitelist approach

In this case we could introduce a whitelist of HTML elements allowed 
directly in SVG, e.g.

     video
     audio
     canvas
     iframe
     input
     button
     p
     (template)

If the set is small enough, adding presentation attributes might be 
palatable? Or maybe not.

I think it's somewhat confusing for authors however?


All-in approach

Basically allow all HTML elements to be used directly in SVG. Or is it 
all flow content? What to do with elements that are not flow content? 
e.g. <li>

If we do this we have to address overlap:

     <font> - fixed by deprecating
     <style> - can probably be aligned?
     <style> - has different semantics but can be aligned???

This is probably the hardest for authoring tools since they have to 
either support all of HTML (is it possible to use a WebView or something 
for those parts of the tree?) or otherwise explain to users why the text 
that's wrapped in a <p> isn't showing. Of course, that's only an issue 
for tools that support arbitrary input.


The backwards compatibility issue

Suppose we have content with stray unclosed <svg> elements, e.g.

  <!doctype html>
  <svg>
  <div></div>
  <div></div>

If we stop automatically closing the <svg> tag when we see the <div> 
what will happen?

1. Firstly, in all of the above proposals we will at least render the 
div now.
2. But where?
   * We already have a proposal to define SVG layout as something like 
position:absolute with percentages resolved against the outermost SVG 
viewport. Or something along those lines.
   * However, if we do that all the <div>s will end up stacked on top of 
each other, right?
3. And what about the bounds of the <svg>? If no size is specified it 
will get clipped to 300px wide.
   * We can fix that by making <svg> overflow:visible by default. IE 
already does this.
   * However, will percentage units will still be sized according to a 
300px viewport? Will that matter?


Yet another approach: <box>

If all this proves too hard, we could just allow <template> and other 
new elements without backwards compatibility issues, and wrap other 
elements in <box>.

That would give us:

   <box x="50" y="50"><iframe width="100" height="100" 
src="svg.svg"></iframe></box>

That, at least, avoids the compatibility issues and allows adding 
x/y/transform presentation attributes.


Best regards,

Brian

Based on: 
https://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2014/HTML_integration_again

[1] 
https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda/HTML_integration
[2] http://www.w3.org/2014/08/25-svg-minutes.html#item02

Received on Friday, 31 October 2014 17:34:46 UTC