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

Yes!!  Thanks guys...that's exactly the distictions and clarifications I
was looking for...assuming these are acceptable distinctions, definitions
and goals.
On Apr 25, 2012 8:16 PM, "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
>