<template> element capability/semantics in SVG parsing context

[kevinpschaaf]

This is a feature request to provide similar capability/semantics of the HTMLTemplateElement/<template> tag for elements parsed in the SVG namespace.

From a user's point of view, the use cases and reasons that made <template> useful -- ability to parse a prototypical chunk of elements from a document, holding the parsed nodes in an inert fragment, and ability to efficiently clone one or more instances of the template without incurring re-parsing costs or needing to recursively walk a tree to create them -- all apply to elements in the SVG context. However, the <template> tag is only defined in the HTML namespace, and there is no built-in equivalent for SVG.

This seems like an obvious hole in the platform; what are the current blockers to considering such an addition?

[kevinpschaaf]

The original discussions of the <template> proposal that @annevk helpfully pointed to indicate a concern for adding this capability to SVG:

The proposal here doesn't support SVG (or MathML, but SVG seems more important for <template>). Short of hard-coding a list of SVG elements, which seems really bad for forwards compatibility, I don't have a good proposal for dealing with this. I suppose we could go back to having an attribute on <template>, this time setting the context at a more coarse level of just HTML vs SVG vs MathML; that's more likely to be understood by authors than what I was suggesting before ("in table body", etc).

It wasn't immediately clear to this lay person what would necessitate a hard-coded list of SVG elements; it seems like if the parser is parsing in the SVG namespace and there was a <template> element defined in that namespace, it could be a straightforward addition.

[annevk]

What you are suggesting is effectively introducing a new element with equivalent semantics to the template element. That comes at a high cost and is unlikely to gain support given that it duplicates an element and requires changes to the HTML parser (which have a high bar).

If instead the suggestion is changed to make it create an HTML template element, but whose insertion mode sticks with SVG somehow, that would already be far more reasonable, but given #919 (comment) is also unlikely to succeed.

I do think it would be good to figure out something here as SVG is very much part of the platform and it's rather crappy for templates to not support it properly, but it's probably better at this point to take a couple steps back and focus on high-level use cases and requirements first (and perhaps a survey of what frameworks have on offer).

[tabatkins]

And my very next comment #919 (comment) complains about Henri's comment as being discussion-stopping, and provides a solution to fix things. ^_^ (Add a new HTML <vector> element, which acts identically to <svg>, but which parses with the normal HTML parser, and just assigns things to the SVG or HTML namespace as appropriate based on localName.)

[annevk]

I think that has the same issues he's worried about. Namely that introducing new ways to create elements has security implications and even if all browsers updated it's unclear if servers would.