- From: Dimitri Glazkov <dglazkov@chromium.org>
- Date: Wed, 18 Apr 2012 14:54:58 -0700
- To: James Graham <jgraham@opera.com>
- Cc: Henri Sivonen <hsivonen@iki.fi>, public-webapps <public-webapps@w3.org>, Adam Barth <w3c@adambarth.com>, Ian Hickson <ian@hixie.ch>, Rafael Weinstein <rafaelw@google.com>, Erik Arvidsson <arv@google.com>, Yehuda Katz <wycats@gmail.com>
On Wed, Apr 18, 2012 at 2:31 PM, James Graham <jgraham@opera.com> 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<
Received on Wednesday, 18 April 2012 21:55:30 UTC