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?
Received on Wednesday, 18 April 2012 21:32:13 UTC