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

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

From: Clint Hill <clint.hill@gmail.com>
Date: Mon, 23 Apr 2012 20:42:08 -0700
To: public-webapps <public-webapps@w3.org>
Message-ID: <CBBB6D6A.719B%clint.hill@gmail.com>
I'd like to weigh in on this topic as it is something that I'm involved in
at work as well.

Could you maybe explain further "parsing the template contents as HTML Š
can contain sub templates"?

If you take this example:

<template>
    <div><!-- A little markup //--></div>
    <template><!-- subtemplate markup //--></template>
    <div><!-- A little more markup //--></div>
</template>

Are you saying there is 1 Node that has a 3 children? If "yes" what
benefit does that bring that inert tags doesn't?


On 4/23/12 8:25 PM, "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<
>>>>
>>>
>>
>
Received on Tuesday, 24 April 2012 03:42:43 GMT

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