- From: Rafael Weinstein <rafaelw@google.com>
- Date: Wed, 18 Apr 2012 11:11:30 -0700
- To: Dimitri Glazkov <dglazkov@chromium.org>
- Cc: 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 9:32 AM, Dimitri Glazkov <dglazkov@chromium.org> wrote: > 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. I've created a bug against the spec to make clear that the XML parser will be unchanged WRT the template element. https://www.w3.org/Bugs/Public/show_bug.cgi?id=16787 > >> >> 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 18:12:04 UTC