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

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?

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 14:50:26 UTC