On Wed, 18 Apr 2012, Dimitri Glazkov wrote:
Wouldn't it make more sense to host the template contents as normal
descendants of the template element and to make templating APIs accept
either template elements or document fragments as template input? Or
to make the template elements have a cloneAsFragment() method if the
template fragment is designed to be cloned as the first step anyway?
When implementing this, making embedded content inert is probably the
most time-consuming part and just using a document fragment as a
wrapper isn't good enough anyway, since for example img elements load
their src even when not inserted into the DOM tree. Currently, Gecko
can make imbedded content inert on a per-document basis. This
capability is used for documents returned by XHR, createDocument and
createHTMLDocument. It looks like the template proposal will involve
computing inertness from the ancestor chain (<template> ancestor or
DocumentFragment marked as inert as an ancestor). It's unclear to me
what the performance impact will be.
Right, ancestor-based inertness is exactly what we avoid with sticking
the parsed contents into a document fragment from an "inert" document.
Otherwise, things get hairy quick.
I am also pretty scared of tokenising stuff like it is markup but then
sticking it into a different document. It seems like very surprising
behaviour. Have you considered (and this may be a very bad idea) exposing
the markup inside the template as a text node, but exposing the
corresponding DOM as an IDL attribute on the HTMLTemplateElement (or
whatever it's called) interface?
