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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 18 Apr 2012 10:42:14 -0700
Message-ID: <CAAWBYDDiSBggKy7GJ4VC=Ow9H0RSw+iUUhPK5=spD2A5jiFk5A@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:51 GMT