[w3c/webcomponents] Template in a SVG context does not have any content (#744)

In Polymer, we had an issue where our `<template is="dom-repeat">` and `<template is="dom-if">` were not compatible in a SVG context (https://github.com/Polymer/polymer/issues/1976). We are working on a fix in https://github.com/Polymer/polymer/pull/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:

```js
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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/744