On Wed, Apr 18, 2012 at 2:31 PM, James Graham <[email protected]> wrote: > 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?
This seems like a neat idea -- though I haven't thought about this in depth yet. :DG<
