- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 25 Apr 2012 16:22:23 -0700
- To: Ojan Vafai <ojan@chromium.org>
- Cc: Brian Kardell <bkardell@gmail.com>, Clint Hill <clint.hill@gmail.com>, Kornel LesiĆski <kornel@geekhood.net>, Dimitri Glazkov <dglazkov@chromium.org>, public-webapps@w3.org
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