Add an option to <use> elements to create independent, unlinked clones

[AmeliaBR]

The copied graphics created by a <use> element are live mirrors of the original referenced DOM elements. They must reflect any mutations on the original, and cannot be modified directly.

This means that the cloned elements cannot be fully animated or manipulated independently. It also means that implementations must maintain mutation listeners on the source DOM fragments. And it means that interactive content is a usability mess (see #183).

I know of multiple SVG authors who currently use JS frameworks to clone SVG document fragments because <use> elements just don't offer the necessary independence of each instance.

I am therefore proposing a new attribute on the <use> element, which would switch it from being a linked mirror of the referenced DOM fragment to being an independent clone.

Attribute name could be method or shadow (or shadow-method). Values would be clone or mirror, with initial value mirror, to reflect the current behavior.

For static SVG renderers, this attribute would have no effect; it would only impact animation and scripting. And probably only interactive animation at that, but I'm not certain without writing up a full proposal.

For script-supporting user agents, it would require very little additional complexity beyond the switch to a full shadow-DOM element model (as opposed to the SVG 1.1 element instance model). If anything, it would move the <use> element closer to the web components shadow DOM implementation. Independent clones means that the shadow DOM elements are no longer read-only from the perspective of author scripts, and no longer modified by the user agent in response to DOM mutations on the referenced graphics.

The only complication is defining at exactly what point the cloning occurs. It would have to be at the later of: when the <use> element is fully parsed & added to the DOM, and when the referenced element is fully parsed & added to the DOM.

This is something for a new module (unless we have some really keen implementer responses), but I will be making sure the SVG 2 use element re-write supports the possibility.

[progers]

Would it be possible to achieve the same goals by better supporting existing web components apis? A custom element extending from SVGElement is similar to a modern <use> but isn't possible today due to spec restrictions.

[AmeliaBR]

@progers

I'm still open to the idea of implementing custom elements in SVG, and I think others on the WG are, too. However, this is a more limited proposal: no custom elements with unique functionality, just a shadow DOM of regular SVG elements doing what they usually do.

The benefit of implementing it as an extension to <use> is that you would still get the basic non-interactive cloning behavior in user agents or security situations that don't support scripting. So your markup could define repeated objects that display even in a static image, but in interactive environments, each instance could react independently.

But as you say, once we get <use> elements implemented in a way that is fully compatible with shadow DOM, there won't be many differences between that and a web component that instantiates an HTML <template> without adding extra functionality. It would just be a declarative, backwards-compatible way to do it in SVG.