W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

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

From: Rafael Weinstein <rafaelw@google.com>
Date: Wed, 8 Feb 2012 15:33:29 -0800
Message-ID: <CABMdHiSa+LwRFnqRgm_ZZLZ6Ef8f2qcHekjcrrjOJ9oLLp7iag@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: Erik Arvidsson <arv@chromium.org>, Dimitri Glazkov <dglazkov@chromium.org>, public-webapps <public-webapps@w3.org>, Henri Sivonen <hsivonen@iki.fi>, Ian Hickson <ian@hixie.ch>
On Wed, Feb 8, 2012 at 3:16 PM, Adam Barth <w3c@adambarth.com> wrote:
> On Wed, Feb 8, 2012 at 2:47 PM, Rafael Weinstein <rafaelw@chromium.org> wrote:
>> Here's a real-world example, that's probably relatively simple
>> compared to "high traffic" web pages (i.e. amazon or facebook)
>>
>> http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/template/api_template.html?revision=120962&content-type=text%2Fplain
>>
>> that produces each page of the chrome extensions API doc, e.g.
>>
>> http://code.google.com/chrome/extensions/contextMenus.html
>>
>> This uses jstemplate. Do a search in the first link. Every time you
>> see "jsdisplay" or "jsselect", think <template>.
>
> It's a bit hard for me to understand that example because I don't know
> how jstemplate works.

Sorry. This example wasn't really meant to be understood so much as
observed for:

1) A general feel for levels of nesting.
2) That the nested components are defined where they are used.
3) How complex the templating already is, even given that templates
can be nested.
3) Imagine what this page might look like if each nested component was
pulled out and put somewhere else (possibly the top level).

>
> I'm just suggesting that rather than trying to jam a square peg
> (<template>) into a round hole (the HTML parser), there might be a way
> of reshaping both the peg and the hole into an octagon.

I get that. Unfortunately, I'm useless on this front because I know
next to nothing about HTML parsing.

All I can offer is an opinion as to how well various declarative
semantics will address the templating use case.

Maybe the best analogy I can give is this: try to imagine if someone
proposed that C looping constructs couldn't contain a body -- only a
function call. e.g.

for (int i = 0; i < count; i++) doMyThing();

You can still write all the same programs, but it'd be an
unfortunately feature to give up.

>
> Adam
>
>
>> On Wed, Feb 8, 2012 at 2:36 PM, Adam Barth <w3c@adambarth.com> wrote:
>>> On Wed, Feb 8, 2012 at 2:20 PM, Erik Arvidsson <arv@chromium.org> wrote:
>>>> On Wed, Feb 8, 2012 at 14:10, Adam Barth <w3c@adambarth.com> wrote:
>>>>> ... Do you have a concrete example of
>>>>> where nested <template> declarations are required?
>>>>
>>>> When working with tree like structures it is comment to use recursive templates.
>>>>
>>>> http://code.google.com/p/mdv/source/browse/use_cases/tree.html
>>>
>>> I'm not sure I fully understand how templates work, so please forgive
>>> me if I'm butchering it, but here's how I could imagine changing that
>>> example:
>>>
>>> === Original ===
>>>
>>> <ul class="tree">
>>>  <template iterate id=t1>
>>>    <li class="{{ children | toggle('has-children') }}">{{name}}
>>>      <ul>
>>>        <template ref=t1 iterate=children></template>
>>>      </ul>
>>>    </li>
>>>  </template>
>>> </ul>
>>>
>>> === Changed ===
>>>
>>> <ul class="tree">
>>>  <template iterate id=t1>
>>>    <li class="{{ children | toggle('has-children') }}">{{name}}
>>>      <ul>
>>>        <template-reference ref=t1 iterate=children></template-reference>
>>>      </ul>
>>>    </li>
>>>  </template>
>>> </ul>
>>>
>>> (Obviously you'd want a snappier name than <template-reference> to
>>> reference another template element.)
>>>
>>> I looked at the other examples in the same directory and I didn't see
>>> any other examples of nested <template> declarations.
>>>
>>> Adam
Received on Wednesday, 8 February 2012 23:34:01 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:50 GMT