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. > > ~TJReceived on Wednesday, 25 April 2012 23:33:43 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:33 UTC