Re: [webcomponents] More backward-compatible templates

Additionally, <template> is needed to ensure that contained content is
inert (just parsed, does not trigger behavior). A hidden <div> triggers
behavior when many constructs are parsed (script, img, style, for example)

-- Yehuda Katz
(ph) 718.877.1325
On Nov 2, 2012 2:30 PM, "Brian Kardell" <bkardell@gmail.com> wrote:

> The reason is because all of the things that you do in every template
> system (iteration, conditionals, etc) are also intended to be <template>.
>
> It kinda messes with the mind to get used to that idea, even for me I
> occasionally need reminding...
>
> http://memegenerator.net/instance/29459456
>
> Brian Kardell :: @bkardell :: hitchjs.com
> On Nov 2, 2012 5:18 PM, "Glenn Maynard" <glenn@zewt.org> wrote:
>
>> I'm coming into this late, but what's the purpose of allowing nested
>> templates (this part doesn't seem hard) and scripts in templates, and what
>> does putting a script within a template mean?  (It sounds like it would run
>> the script when you clone the template, but at least in the <template>
>> example at the top, that doesn't look like what would happen.)  It sounds
>> closer to a widget feature than a template.
>>
>> I template HTML in HTML simply by sticking templates inside a hidden div
>> and cloning its contents into a DocumentFragment that I can insert wherever
>> I want.  The templates never contain scripts (unless I really mean for them
>> to be run at parse time).  I never nest templates this way, but there's
>> nothing preventing it.
>>
>> It would be useful to have a <template> that works like that, which
>> simply gives me a "clone contents into DocumentFragment" function
>> (basically cloneNode(true), but returning a top-level element of
>> DocumentFragment instead of HTMLTemplateElement), and hints the browser
>> that the contents are a template (eg. it may want to deprioritize loading
>> images within it).  It wouldn't be intended to hold script, and if you did
>> put script blocks inside them they'd just be run when parsed (since that's
>> what browsers today will do with it).  It requires no escaping at all, and
>> parses like any other tree, unlike the <script> approach which would just
>> be an opaque block of text, so you couldn't manipulate it in-place with DOM
>> APIs and it'd take a lot more work to make it viewable in developer tools,
>> etc.
>>
>> This would essentially be a CSS rule "template { display: none; }" and an
>> interface that gives a "cloneIntoFragment" (or something) method.
>>
>> With the more complicated approaches people are suggesting I assume there
>> are use cases this doesn't cover--what are they?
>>
>> --
>> Glenn Maynard
>>
>>
>>