F2F/London 2014/Agenda/HTML integration

From SVG
< F2F‎ | London 2014‎ | Agenda
Jump to: navigation, search


  • Want to nest other SVG tiles
    • <image> behaves like <img>: no interactivity, script, external references etc. Need something more like <iframe>. → proposal to add <iframe> directly to SVG
  • SVG 1.2T has <video>, <audio>, people want to use <canvas> in SVG
  • By adding directly to SVG, no need to wrap in <foreignObject> which is crufty (especially when defining a lot of tiles)—not just a long, awkward name, but also necessity of marking namespace on children.
  • Also, people sometimes want to put <div> etc. directly in SVG
  • Want to use other HTML features like <template> without having to wrap them
  • Wrapping <iframe> in <foreignObject> means you have to manage two viewports (three if you count the embedded SVG file) just to embed some content.
  • It would be nice to remove <foreignObject> one day since it is not as thoroughly optimized/tested as other elements

Steps since then:


  • Allow actual HTML elements as direct children of SVG elements with no intervening <foreignObject>.
  • Mechanism (based largely on [1]):
    • When an HTML element is a child of an SVG element, perform CSS layout of the HTML element treating the nearest SVG viewport as the containing block. User-space width/height of this viewport become the width/height of the containing block in CSS pixels.
    • Treat such HTML elements as position:relative
    • We already plan to have x/y properties, but we could also probably make these attributes on HTMLElement (combining roc's proposal with Dirk's feedback here). (Workaround needed for HTMLImageElement's x/y)
    • Likewise, we could make ‘transform’ a presentation attribute on HTMLElement.

Issue #1: Parsing

  • For the following fragment
<!doctype html>
<span id="s"></span>
<div id="i"></div>

"s" and "i" are already put in the HTML namespace but as siblings of the <svg> element, not as descendants. The HTML parser breaks out of SVG mode when it sees these because there was some content on the Web that had an open <svg> element at the start of the document and no closing one. No-one knows why but if you stay in SVG mode, the rest of the document is not rendered, hence the break out mode. [2][3][4]

  • However, if we made these descendants of the <svg> and if we also made HTML descendants of SVG rendered, we'd be ok right? [5]
  • Not quite, since SVG is overflow:hidden by default [6][7]
    • Question about whether this could be changed to overflow:visible for SVG for [8]. Does IE already do this?
  • General sentiment is that it might be worth breaking those crazy sites for the sake of this change [9][10][11][12] but some opposition: [13]

Issue #2: Defining layout

  • Question about supporting position:static / position:absolute so that these HTML elements don't have a different default position.
  • Refined proposal featuring SVG layout model
    • Use !important rule in UA stylesheet to trigger SVG layout mode on <svg>
    • Descendant SVG elements propagate this mode (probably via UA stylesheet) so they can continue to use display:whatever
    • Descendant HTML elements don't propagate this mode and hence are laid out normally (position:static with x/y does what you'd expect)
  • Apparently these layout attributes should be described as presentational hints

Where to from here:

  • Other technical issues to resolve, data to be gathered?
  • Coordination with HTML people
  • What to do with embedded content chapter in SVG2?