Template in a SVG context does not have any content

[TimvdLippe]

In Polymer, we had an issue where our <template is="dom-repeat"> and <template is="dom-if"> were not compatible in a SVG context (Polymer/polymer#1976). We are working on a fix in Polymer/polymer#5135, but have hit an issue with the template element in a SVG context.

Please see the following reproduction case: http://jsbin.com/dufavefufu/edit?html,console,output Whenever a template element is included inside an svg element (or in general in the SVG namespace), the template element has no content. Instead, the template element does have childNodes. Our "fix" is therefore the following:

function replaceNamespacedTemplate(template) {
  if (!template.content && template.namespaceURI !==
      document.documentElement.namespaceURI) {
    const htmlTemplate = /** @type {HTMLTemplateElement} */
      (document.createElement('template'));
    while (template.firstChild) {
      htmlTemplate.content.appendChild(template.firstChild);
    }
    template.parentNode.replaceChild(htmlTemplate, template);
    return htmlTemplate;
  }
  return /** @type {HTMLTemplateElement} */ (template);
}

Here we detect that the namespace of the template we are iterating over is not the HTML namespace. Then we create a regular template in the HTML namespace and move over all children of the original "broken" template into the new template. This works, as the original children are parsed in the SVG namespace and will therefore be correctly constructed.

However, we are not sure whether this is actually proper behavior. Is it expected behavior to patch up the template element in a different namespace in this way? In any case, our expectation was that the template inside a svg has a content property which contains the DOM Nodes constructed in the correct namespace.

We would like to get this behavior clarified (and potentially specced), as we could not find any mention of expected behavior in the current specification. We would like to prevent shipping code like this if it would rely on wrong behavior.

CC @sorvell @kevinpschaaf @azakus

[domenic]

This isn't a web components issue, but a HTML issue. As such I'd suggest filing it on whatwg/html, as here it's not going to have the right subject matter experts.

I am fairly certain this is behaving per spec, but I'm not able to find it right now. SVG definitely changes the rules for all sorts of its children. Since you're not creating an actual HTML template element, but instead a SVG template element (which doesn't exist), it's definitely going to put things into the template contents document.

[domenic]

What's interesting here is that, unlike div or span, adding a template inside your svg element does not close the svg element and put the template element after it in the DOM.

You have to use foreignObject to embed HTML elements in SVG usually, and this gets enforced by "punishing" you by closing your SVG element and pushing the would-be-nested HTML element outside the SVG element. But for template that "punishment" isn't happening, and instead you just get a SVG template element, which behaves the same as a SVG asdf element.

This effect also concurs with several other elements like html, applet, and marquee. I think I've found a relevant section of the spec but don't quite have all the pieces.

[annevk]

That's because of https://html.spec.whatwg.org/multipage/parsing.html#parsing-main-inforeign "any other start tag". There's only a limited set of HTML elements that cannot be used in an SVG/MathML context.

[kevinpschaaf]

I think what we'd actually like is to open discussion about the potential for an SVGTemplateElement to be added to the platform (with otherwise identical behavior to HTMLTemplateElement, consuming its SVG-namespaced child elements into its .content fragment), or some other means of getting equivalent functionality.

It seems like a hole that we have a platform primitive for parsing and then efficiently cloning copies of inert HTML but not SVG; and more-so that we're considering adding more functionality to <template> ala TemplateInstantiation which would currently exclude SVG use cases (despite the fact that a developer needing to repeat a list of svg fragments from a template is arguably no stranger than needing to repeat a list of divs).

Is that still a whatwg/html concern, or does it belong here?

Also, was template support in SVG litigated in the original <template> discussions and rejected or deferred for some reason?

[domenic]

Yeah, none of that has to do with web components; definitely worth filing on the appropriate repo.

I'm not sure about the original template discussions; it'd be worth trying to look in the archives.

[annevk]

There's a thread starting at https://lists.w3.org/Archives/Public/public-webapps/2012AprJun/1061.html about this, but it seems it basically got dropped since there was no good answer as to how to do it. We could introduce a mode-switch attribute perhaps, but it's unclear if that works for all use cases.

[rniwa]

It seems like this should be discussed in conjunction with a broader goal of supporting web components in SVG in general.

[TimvdLippe]

Thanks for the speedy and numerous responses! I am okay with moving this discussion to whatwg/html if that is a more appropriate location.

[TimvdLippe]

Moved the issue to whatwg/html#3553