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

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<
>>
>>
>