- 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