- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Fri, 31 Oct 2014 10:34:25 -0700
- To: 'www-svg' <www-svg@w3.org>
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