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

I agree with these statements:
"there is no use for the contents before it is used programmatically"
"it's never considered to be part of the document's semantic content"

I'd like to add that the only use-case for a <template/> tag (IMO) is to
deliver content to the UA safely preventing the DOM from using it. I would
never want the UA to present this content or place it in the element stack
before something has programmatically manipulated it.

To have the UA parse it and add it to the element stack seems problematic in
that it would possibly have to be reversed out once I'm done manipulating
it.

From:  Yuval Sadan <sadan.yuval@gmail.com>
Date:  Tue, 24 Apr 2012 18:57:46 +0300
To:  Rafael Weinstein <rafaelw@google.com>
Cc:  public-webapps <public-webapps@w3.org>, Ryosuke Niwa <rniwa@webkit.org>
Subject:  Re: [webcomponents] HTML Parsing and the <template> element
Resent-From:  <public-webapps@w3.org>
Resent-Date:  Tue, 24 Apr 2012 15:58:26 +0000


Placing contents as CDATA is an option. I personally think the <template/>
tag as proposed is adhoc to somebody's notion of how templates should work.
To avoid this I think they should be simpler. I am not seeing the added
advantage of having the client parse the contents upon encountering it:
there is no use for the contents before it is used programatically, and as
such it could be prepared on first use, via the DocumentFragment suggestion
mentioned earlier. Specifically, it's never considered to be part of the
document's semantic content. Perhaps I'm overlooking something here.

I would recommend adding a mime type specifier to the template. Choosing
text/html as a content type may hint that contents should be parsed.
Alternatively or additionally an attribute indicating that the contents
should be parsed as DOM may be specified, e.g. <template html/> or <template
dom/>.

On Apr 24, 2012 6:25 AM, "Rafael Weinstein" <rafaelw@google.com> wrote:
> Yes. I think this issue is a distraction.
> 
> Using the script tag for encoding opaque text contents is a hack, but
> it works as well as it can. AFAIC, The main drawback is that the
> contents cannot contain the string "</script>". This will be the case
> for any new element we came up with for this purpose.
> 
> If someone has an idea for how to do better than this and why it's
> worth doing, please speak up.
> 
> Part of the point of parsing the template contents as HTML is exactly
> so that template contents can contain subtemplates. It's a universal
> feature of templating systems and needs to be well supported.
> 
> On Mon, Apr 23, 2012 at 4:11 PM, Ryosuke Niwa <rniwa@webkit.org> wrote:
>> > Why don't we just use script elements for that then?
>> >
>> >
>> > On Mon, Apr 23, 2012 at 3:52 PM, Yuval Sadan <sadan.yuval@gmail.com> wrote:
>>> >>
>>> >> 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<
>>>> >>>
>>> >>
>> >