W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: [webcomponents] HTML Parsing and the <template> element

From: Rafael Weinstein <rafaelw@google.com>
Date: Wed, 18 Apr 2012 11:11:30 -0700
Message-ID: <CABMdHiRHONOqZcEz6SxK+S1oB9wgSvGrWe5Vx7c5svgGYasptw@mail.gmail.com>
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.


>> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:33 UTC