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

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)

>
> If iteration uses a different tagname than normal templating (say,
> <iterate>), thus avoiding the "nesting <template> in <template>"
> problem, you still have the problem of nesting iteration, which is
> *also* a common ability for template systems.

I think this might be in response to my comment about talking about
them with different names.  This was purely for discussion purpose to
point out they are generally different things.  It was not a
suggestion.  Still, it hinges on the notion that the template syntax
is HTML-like and interspersed in HTML.  As many people have shown,
this is not what a lot of people are thinking.  A lot of questions
indicate that most people will simply reserialize and treat it as a
string.  Maybe that's wrong, I don't know - but it seems there would
be some value in getting everyone on the same page there.

> Any way you slice it, common templating scenarios will create problems
> if you don't hook it up to a proper parser at some point.

Today we have proper (and some not exactly proper) parsers written in
JavaScript to do templating (and all kinds of other useful things)...
It feels to me like it would be nicer if we could somehow take
advantage of the lexing / parser generator capabilities that the
browsers have in their codebase so that those libraries could not have
to rewrite that stuff over and over again.

> Might as
> well do that early so you can immediately delve into it with DOM
> methods and whatnot, rather than delaying it and keeping it as flat
> text until the point of use.

You can only really delve into it usefully with DOM methods if the
stuff inside  (meaning all of the instructions and everything) _look_
like HTML though - right?

Received on Tuesday, 24 April 2012 17:15:29 UTC