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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 24 Apr 2012 10:50:03 -0700
Message-ID: <CAAWBYDBD19Q6ZrN4T6WUL-y4Ht1HTR4=PkoVtqPBvkuxbnBUzQ@mail.gmail.com>
To: Brian Kardell <bkardell@gmail.com>
Cc: Clint Hill <clint.hill@gmail.com>, Erik Arvidsson <arv@chromium.org>, Rafael Weinstein <rafaelw@google.com>, Ryosuke Niwa <rniwa@webkit.org>, Yuval Sadan <sadan.yuval@gmail.com>, public-webapps <public-webapps@w3.org>
On Tue, Apr 24, 2012 at 10:14 AM, Brian Kardell <bkardell@gmail.com> wrote:
> On Tue, Apr 24, 2012 at 12:45 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Tue, Apr 24, 2012 at 9:12 AM, Clint Hill <clint.hill@gmail.com> wrote:
>>> Hmm. I have to say that I disagree that your example below shows a
>>> template within a template. That is IMO 1 template wherein there is
>>> iteration syntax.
>> The "iteration syntax" is basically an element - the example that Arv
>> gave even used element-like syntax, with open and close tags.  That
>> iteration element is inside of a template.
> But in his example, and most of the ones people have been citing or
> really want to use this for they are  no tags in the HTML sense...
> Those are handlebars (or mustache or dust or haml or whatever)
[snip further comments along similar lines]

As long as it's handlebars that merely *look* like elements, we have
to ship code down the wire that is simply a functional replacement for
the DOM that the user already has.  This is suboptimal.  It's a
cowpath that only curves this way because the straighter path was
blocked by a boulder, and cows don't have dynamite.  We do.

The more we can replace code-on-the-wire with code-in-the-browser, the
better.  (Subject to obvious tradeoffs, of course.)

Received on Tuesday, 24 April 2012 17:50:56 UTC

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