- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 18 Apr 2012 10:42:14 -0700
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: Dimitri Glazkov <dglazkov@chromium.org>, 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? As Dimitri says, it can make "inertness" a little simpler to explain. It also prevents APIs like querySelector from accidentally grabbing the contents of a <template> when they *intend* to grab the "real" DOM produced from the template. ~TJ > This also breaks the natural mapping between XML source and the DOM in > the XML case. > > This weirdness also requires a special case to the serialization algorithm. > > 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. > > 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. > > -- > Henri Sivonen > hsivonen@iki.fi > http://hsivonen.iki.fi/ >
Received on Wednesday, 18 April 2012 17:43:06 UTC