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

Since <template> is a very specialized thing then (inert, boundaries
and all that), and what some people are referring to as templating
(that is, string based stuff that may or may not represent DOM, but is
almost certainly not "pure DOM") is not the intent (IE, we should use
<script> for the cases discussed instead)... Does it make sense for
the API to potentially reflect that and the draft to note it?  For
example... could it either not have an innerHTML property or could
that innerHTML return (empty string) or something?

It seems to me that the draft would be improved by making the
distinction because just given the name of the tag, it is actually
confusing as in common parlance (today anyway) "template" generally
means the other.



On Wed, Apr 25, 2012 at 8:15 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

Received on Thursday, 26 April 2012 17:38:45 UTC