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

On Apr 25, 2012 7:22 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>
> On Wed, Apr 25, 2012 at 3:31 PM, Ojan Vafai <ojan@chromium.org> wrote:
> > <script type=text/html> works for string-based templating. Special
handling
> > of </script> is not a big enough pain to justify adding a template
element.
> >
> > For Web Components and template systems that want to do DOM based
templating
> > (e.g. MDV), the template element can meet that need much better than a
> > string-based approach. If nothing else, it's more efficient (e.g. it
only
> > parses the HTML once instead of for each instantiation of the template).
> >
> > String-based templating already works. We don't need new API for it.
> > DOM-based templating and Web Components do need new API in order to
work at
> > all. There's no need, and little benefit, for the template element to
try to
> > meet both use-cases.
>
> String-based templating *doesn't* work unless you take pains to make
> it work.  This is why jQuery has to employ regex hacks to make
> $('<td>foo</td>') work the way you'd expect.  Fixing that in the
> platform is a win, so authors don't have to ship code down the wire to
> deal with this (imo quite reasonable) use-case.

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?

>
> When you want to do DOM-based templating, such as for Components or
> MDV, you run into the *exact same* problems as the above, where you
> may want to "template" something that, in normal HTML parsing, expects
> to be in a particular context.  Solving the problem once is nice,
> especially since we get to kill another problem at the same time.  We
> aren't even compromising - this is pretty much exactly what we want
> for "full" DOM-based templating.
>
> ~TJ