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

You musn't forget what we're not planning for. Templates can be great for
so many applications - generating code (JSON, Javascript), generating
plain-text or otherwise formatted (markdown, restructured text, etc.)
content and much more. I don't think templates should be parsed by DOM
unless explicitly requested. The simplest scenario should also be supported
imho, that is <script type="text/html"></script>-ish markup with access to
textContent.

On Thu, Apr 19, 2012 at 1:56 AM, Rafael Weinstein <rafaelw@google.com>wrote:

> On Wed, Apr 18, 2012 at 2:54 PM, Dimitri Glazkov <dglazkov@chromium.org>
> wrote:
> > On Wed, Apr 18, 2012 at 2:31 PM, James Graham <jgraham@opera.com> wrote:
> >> On Wed, 18 Apr 2012, Dimitri Glazkov wrote:
> >>
> >>>> 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.
> >>>
> >>
> >> I am also pretty scared of tokenising stuff like it is markup but then
> >> sticking it into a different document. It seems like very surprising
> >> behaviour. Have you considered (and this may be a very bad idea)
> exposing
> >> the markup inside the template as a text node, but exposing the
> >> corresponding DOM as an IDL attribute on the HTMLTemplateElement (or
> >> whatever it's called) interface?
> >
> > This seems like a neat idea -- though I haven't thought about this in
> depth yet.
>
> I think there are two orthogonal issues here:
>
> 1) Are the contents of the template element (a) parsed, context-free
> in a separate document which lacks a browsing context, or (b) simply
> processed as text.
> 2) Where are the contents of the template element put.
>
> (I'm separating these because James' proposal is about the second, not
> the first).
>
> I think there's a disconnect here between what seems strange to us a
> UA implementors and what isn't strange at all to webdevs. In a way,
> the goal here is exactly to create a mechanism which is strange in
> this way.
>
> Effective, every web app that does client-side templating is totally
> used to this idea: E.g. I want to ship fragments of DOM structures
> inside my document to the client, but have those fragments exist
> *outside* the DOM constructed for that document for all practical
> purposes (rendering, traversal, resource loading, selector matching,
> etc...).
>
> This goal of this feature is provide webdevs with a supported
> mechanism to do this which lacks the pitfalls of the available hacks.
>
> Assuming (1) is uncontroversially (a), then the idea to re-serialize
> the parsed content and append it is a text child to the template
> element would resolve our worry about the contents living outside the
> DOM being strange, but it has the downside that nearly all uses will
> immediately re-parse.
>
> [Dimitri addressed the problem with (1) being (b) earlier in the
> thread, if anyone is interested].
>
> >
> > :DG<
>
>