W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: [webcomponents] More backward-compatible templates

From: Brian Kardell <bkardell@gmail.com>
Date: Fri, 2 Nov 2012 17:28:39 -0400
Message-ID: <CADC=+je-9hh-tz_VPfPvWSvRfKVTw9xEcnJhzUxSyjkOrUS6fg@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: "public-webapps@w3.org WG" <public-webapps@w3.org>, Maciej Stachowiak <mjs@apple.com>
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...


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
Received on Friday, 2 November 2012 21:29:07 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:49 UTC