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

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

Received on Thursday, 26 April 2012 00:16:30 UTC