W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

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

From: Ojan Vafai <ojan@chromium.org>
Date: Wed, 25 Apr 2012 16:32:41 -0700
Message-ID: <CANMdWTvQ=fcLmJP=z6YF1ONegp8LX3DCq8R_Cjgjyv+YHc7puA@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: (wrong string) „ski <kornel@geekhood.net>, Dimitri Glazkov <dglazkov@chromium.org>, public-webapps@w3.org
On Wed, Apr 25, 2012 at 4: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.
> 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.

I agree with everything your saying, but I think you're mixing up two
different problems here. What you're listing above is not what I'm calling
templating. I would call that programmatic DOM creation. We also have to
solve that problem and, coincidentally, it will also require the same
parsing rules as the ones we're suggesting for template. When I'm talking
about templating, I'm talking about something that involves iteration and
data-binding, e.g. "<script type=text/html><div>{{ myBoundVariable

Received on Wednesday, 25 April 2012 23:33:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:33 UTC