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

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

From: Dimitri Glazkov <dglazkov@chromium.org>
Date: Wed, 25 Apr 2012 13:00:42 -0700
Message-ID: <CADh5Ky3g_+=10jST_zNAgfseCDFYhS9NXkmhNHARLvw5s+R1-Q@mail.gmail.com>
To: Brian Kardell <bkardell@gmail.com>
Cc: (wrong string) ┼„ski <kornel@geekhood.net>, public-webapps@w3.org
On Wed, Apr 25, 2012 at 11:32 AM, Brian Kardell <bkardell@gmail.com> wrote:
>>On Wed, Apr 25, 2012 at 1:57 PM, Dimitri Glazkov <dglazkov@chromium.org> wrote:
>> On Wed, Apr 25, 2012 at 10:45 AM, Brian Kardell <bkardell@gmail.com> wrote:
>>> Earlier in this thread I mentioned "I expect, however, that there
>>> might be larger ideas behind why not to
>>> do this in the sense of web components or declarative MDV-like data binding..."
>>>
>>> I guess this is mostly a question for Dimitri or Dominic, but:
>>> <template> is used/referenced extensively in the Web Components
>>> Explainer[1] -- I am wondering what using template to hold something
>>> like a mustache template (which doesn't use an HTML-like syntax for
>>> things like iterators and thus must be used "as a string") would mean
>>> in the context of those proposals... How would it affect one's ability
>>> to use custom elements, decorators, etc...?
>>
>> Why would we want to consider a solution that requires two-pass
>> parsing and thus is guaranteed to be slower and more error-prone?
>>
>
> The nature of my question isn't whether you/we would want to consider
> replacing the current inert parse with treat it as text... I will let
> someone else address that if they care to.
>
> Regardless, however, it definitely seems to be the case that several
> people here have pointed out that nothing in this prevents one from
> using <template> to send mustache or handlebars templates, then just
> grabbing it with innerHTML or maybe even making some special property
> (originalText or something) available and using it more or less the
> way we do now...
>
> However, the explainer uses <template>s as part of other ideas, like
> <element> and <decorator>. áThe question I am asking then is "If one
> chose to use the manual two pass parse approach above, would that
> affect their ability to use those templates inside of <element> or
> <decorator>?

Ah, I think I understand what you're asking. In custom elements and
decorators, the <template> contents are used to populate the shadow
DOM subtree. You don't have to use the <template> tag, and just
populate the shadow DOM subtree in your own preferred method
(imperatively or by hooking in some other templating system). However,
roll-your-own is pretty much guaranteed to be inferior in terms of
readability and performance.

:DG<

>
> None of the examples in the explainer actually appear to use
> <template> element as anything more than a static chunk of markup, so
> I'm not sure how they are applied/whether a templating language choice
> even matters... Could they (meaning templates used in <element> and
> <decorator>) include token replacement or iteration, etc?

No. Also, as spec'd today, HTML Templates
(http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html)
do not have anything like token replacement or iteration.

:DG<

>
> -Brian
Received on Wednesday, 25 April 2012 20:01:11 GMT

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