F2F/London 2014/Agenda/HTML integration
Background:
- 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:
- Embedded content chapter in SVG 2 from KDDI
- Implementation starts in Gecko (Bug 949435)
- Technical difficulties with multiple inheritance slow down development
- Late in review process, approach of having a separate
<iframe>
in SVG brought into question - Spawns thread on www-svg/whatwg.
Proposal:
- 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> <svg> <span id="s">
<div id="i">
"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 defaultposition
. - → 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)
- Use !important rule in UA stylesheet to trigger SVG layout mode on
- 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?