- From: Rafael Weinstein <rafaelw@google.com>
- Date: Wed, 18 Apr 2012 15:56:45 -0700
- To: Dimitri Glazkov <dglazkov@chromium.org>
- Cc: James Graham <jgraham@opera.com>, Henri Sivonen <hsivonen@iki.fi>, public-webapps <public-webapps@w3.org>, Adam Barth <w3c@adambarth.com>, Ian Hickson <ian@hixie.ch>, Erik Arvidsson <arv@google.com>, Yehuda Katz <wycats@gmail.com>
On Wed, Apr 18, 2012 at 2:54 PM, Dimitri Glazkov <dglazkov@chromium.org> wrote: > 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. I think there are two orthogonal issues here: 1) Are the contents of the template element (a) parsed, context-free in a separate document which lacks a browsing context, or (b) simply processed as text. 2) Where are the contents of the template element put. (I'm separating these because James' proposal is about the second, not the first). I think there's a disconnect here between what seems strange to us a UA implementors and what isn't strange at all to webdevs. In a way, the goal here is exactly to create a mechanism which is strange in this way. Effective, every web app that does client-side templating is totally used to this idea: E.g. I want to ship fragments of DOM structures inside my document to the client, but have those fragments exist *outside* the DOM constructed for that document for all practical purposes (rendering, traversal, resource loading, selector matching, etc...). This goal of this feature is provide webdevs with a supported mechanism to do this which lacks the pitfalls of the available hacks. Assuming (1) is uncontroversially (a), then the idea to re-serialize the parsed content and append it is a text child to the template element would resolve our worry about the contents living outside the DOM being strange, but it has the downside that nearly all uses will immediately re-parse. [Dimitri addressed the problem with (1) being (b) earlier in the thread, if anyone is interested]. > > :DG<
Received on Wednesday, 18 April 2012 22:57:17 UTC