- From: Dimitri Glazkov <dglazkov@chromium.org>
- Date: Wed, 18 Apr 2012 09:32:37 -0700
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: 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 7:49 AM, Henri Sivonen <hsivonen@iki.fi> wrote: > On Tue, Apr 3, 2012 at 1:21 AM, Dimitri Glazkov <dglazkov@chromium.org> wrote: >> Perhaps lost among other updates was the fact that I've gotten the >> first draft of HTML Templates spec out: >> >> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html > > "Once parsed, the template contents must not be in the document tree." > > That's surprising, radical and weird. Why are the template contents > hosted in a document fragment that the template element points to > using a non-child property? Why aren't the template contents simply > hosted as a subtree rooted at the template element? In terms of weirdness, this is not much different from the textarea, script, or xmp. It does change the existing behavior, so anyone using a <template> tag today will suddenly find no child nodes -- that part _is_ a bit surprising. However, moving this into a separate document fragment allows us to easily define the boundaries of intertness. If you look at the spec, the document fragment is indeed created from a separate document is inert (like createHTMLDocument case): http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#dfn-template-contents-initialization. > > This also breaks the natural mapping between XML source and the DOM in > the XML case. True. > > This weirdness also requires a special case to the serialization algorithm. True. > > If the document fragment wasn't there and the contents of the template > were simply children of template element, the parsing algorithm > changes would look rather sensible. Great! > > 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. :DG< > > -- > Henri Sivonen > hsivonen@iki.fi > http://hsivonen.iki.fi/
Received on Wednesday, 18 April 2012 16:33:10 UTC