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

I totally misread the purpose of templates beforehand -- <template/>s act
more like a mixin rather than a fill-in. It also reflects in what Tab wrote
that it's still vague how the two notions - that of text templates and that
of mixins for building components - are to be mixed together, if at all.

Re the use as mixins - <template/>s put together two different ideas.
On on hand, it looks like a content-generating/replicating scheme, such as
a CSS content:"", or the proprietary CSS -moz-element:[3] properties. In
that sense, <template/> seems to take these a step further.  From the
spec[1]:

> One reason for creating a document fragment is to clone it multiple times
> to create repeating items that vary in some content, but have common basic
> structure of across all instances.

I see the content as being the DOM, and the common basic structure as the
functional *design* around it. If repeated data was to be a semantic part
of content, I would imagine it would have been incorporated in the tree.

On the other hand, it seems <template/>s are trying to answer the same need
as XML: giving an alternative for semantic structuring of the document
without loosing the ability to add functionality. Again from the spec:

> something that allows developers declare arbitrary DOM subtrees *in* the
> document markup.

I realized as I'm writing this that <template/>s come from XBL so I
shouldn't be surprised.

So I think these points still need some thought:
- should functional design detail be embedded in the document? It looks
like this might be subset of HTML targeting solely user-interactive
web-apps. If it is, it should either be left to another mechanism to solve
than the DOM, or we might encourage attaching these <template/>s as
external files (there is no mention of a <template src=""/> attribute)

- existing techniques have DOM fragments hidden with style="display:none;"
and then replicating them programmatically. What benefits do <template/>s
present? That the fragment is inert, and the declarative nature of insert
points and such. If these are the advantages, then we can add an inert=""
or template="" attribute that any <div/>. Enriching HTML with useful
elements is good, but creating a new subset for the purpose of inert
content and insert points brings a lot of logic to the browser-side. I
think HTML 5 is more about being simple and direct.

- how does this answer the need to separate functional design/layout from
semantic structure? This seems to replace techniques the such as  XML+XSLT
or XBL to render content as you wish. From the XBL spec [2]:

> XSLT operates on a static DOM, permanently replacing that DOM for
> rendering. XBL, on the other hand, transparently transforms the DOM for
> rendering while leaving the underlying structure intact, and dynamically
> reflects changes to the underlying DOM in the transformed rendering.

In light of what I wrote about, why should this functionality be replicated
to the HTML realm (as the specs say) and not used by it? The specs are
missing this motivation. XBL may be used alongside CSS and scripts, instead
of merging them inside HTML.

Since I'm joining this discussion after a lot of specs have been written I
might be missing some key points, but if for nothing else - then let these
be for the sake of pointing these questions out and answering them more
clearly in the specs for the sake of future developers.

Yuval

[1]:
http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html
[2]: http://dev.w3.org/2006/xbl2/
[3]: https://developer.mozilla.org/en/CSS/-moz-element

On Thu, Apr 26, 2012 at 3:15 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Wed, Apr 25, 2012 at 4:33 PM, Brian Kardell <bkardell@gmail.com> wrote:
> > Tab, are you saying:  a) fixing that in script apis for document
> fragment or
> > something is an ok solution to this, or that b) this means text templates
> > should use <template> or c) it should be the goal to kill string
> templates
> > altogether?
>
> I just talked with Ojan in person, because we were talking past each
> other with the terms we were using.  I now understand what he was
> saying!
>
> When we say "string-based templating", we're really saying "I want to
> embed an arbitrary foreign language into HTML".  That language happens
> to be a templating language, but the exact purpose you're putting it
> to is irrelevant for our purposes here.  For this, <script type=foo>
> is not only a satisfactory existing solution to this, but it's the
> *correct* solution to this - that's precisely what <script> is
> designed to do.
>
> I was confusing this term with the idea of "programmatic DOM creation
> that doesn't suck".  Right now, the "right" way to create a fragment
> of HTML is to use a lot of document.createElement() and
> el.appendChild().  This sucks.  Instead, everyone wants to just write
> a string containing HTML and parse it, like what innerHTML and jQuery
> do.  For this, Raf's proposal works great - it lets you use the
> "innerHTML API" without having to employ hacks like jQuery uses to
> ensure that things parse in the right context.
>
> Related closely to this is stuff like a Web Component that wants to
> fill itself with a DOM fragment.  Right now, you're required to do
> that within script.  This sucks, partially because of the
> aforementioned existing suckiness with DOM building.  Even once we fix
> that with Raf's proposal, it will still suck, because it means that
> Components are required to run script to build themselves, even if
> their DOM structure is totally static and doesn't depend on outside
> data.  We want <template> to help us solve this problem, by letting us
> send HTML structure *in HTML* and potentially hook it up to a
> component declaratively, so components don't need to run script unless
> they're actually doing something dynamic.  Parsing the contents of a
> <template> "correctly" requires the same mechanism that Raf is
> proposing.
>
> Somewhat further away, we have another proposal, MDV, which *is*
> intending to replace the basic functionality of the current
> "templating" libraries.  It takes something representing an inert DOM
> structure with holes punched in it for data to fill in, hooks it up to
> a JS object full of data, and pops out a fragment of "real" DOM with
> all the holes filled in.  This is obviously useful when done purely
> via script (the popularity of templating libraries attests to that!),
> but there's intriguing design-space around *declarative*
> templating/iteration, where you just declare a template in markup,
> tell it how to fetch a data source to use, and it handles the rest for
> you.  No script required!  This is very similar to the "no-script
> Components" use-case, and so it would be nice to reuse <template>.
> Even if we use a differently-named element, the parsing problems are
> identical, and we still need something like Raf's proposal to solve
> them.  (Even ignoring the pure-declarative case, being able to ship
> your templates in the page HTML and just grab them with script when
> you want to use it seems useful.)
>
>
> A "text template" like handlebars (in other words, a foreign language)
> should be able to use a significant fraction of the stuff that MDV
> provides.  It will have to parse itself into a DOM structure with the
> "holes" set up manually, but once you've done so it should be able to
> be used in many of the same contexts.  This has nothing to do with the
> <template> tag, though, because it's not *trying* to parse as HTML -
> they should use <script>.
>
> This isn't *completely* ideal - if you are *almost* fine with the
> functionality that MDV provides, but need just a little bit more, you
> either have to switch from <template> to <script> (which isn't
> trivial), or embed your extra functionality in the HTML via @data-* or
> something, which may be a bit clumsy.  We'll see how bad this is in
> practice, but I suspect that once MDV matures, this will become a
> minor problem.
>
> ~TJ
>
>