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

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.

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

Received on Wednesday, 25 April 2012 23:23:13 UTC