W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: [webcomponents] More backward-compatible templates

From: Yehuda Katz <yehuda.katz@jquery.com>
Date: Tue, 30 Oct 2012 13:56:59 -0700
Message-ID: <CAMFeDTXfgNxQfK_j-7iBPhqQyjhnmhBG+y9m59o4A4pUrRZU5A@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: "public-webapps@w3.org WG" <public-webapps@w3.org>
On Tue, Oct 30, 2012 at 6:58 AM, Maciej Stachowiak <mjs@apple.com> wrote:

> In the WebApps meeting, we discussed possible approaches to <template>
> that may ease the transition between polyfilled implementations and native
> support, avoid HTML/XHTML parsing inconsistency, and in general adding less
> weirdness to the Web platform.
> Here are some possibilities, not necessarily mutually exclusive:
> (1) <template src>
> Specify templates via external files rather than inline content. External
> CSS and external scripts are very common, and in most cases inline scripts
> and style are the exception. It seems likely this will also be true for
> templates. It's likely desirable to provide this even if there is also some
> inline form of templates.
> (2) <template srcdoc>
> Use the same approach as <iframe srcdoc> to specifying content inline
> while remaining compatible with legacy parsing. The main downside is that
> the required escaping is ugly and hard to follow, especially in the face of
> nesting.
> (3) <script type=template> (or <script language=template>?)
> Define a new script type to use for templates. This provides almost all
> the syntactic convenience of the original <template> element - the main
> downside is that, if your template contains a script or another nested
> template, you have to escape the close script tag in some way.
> The contents of the script would be made available as an inert DOM outside
> the document, via a new IDL attribute on <script> (say,
> HTMLScriptElement.template).
> Here's a comparison of syntaxes:
> Template element:
> <template>
>     <div id=foo class=bar></div>
>     <script> something();</script>
>     <template>
>          <div class=nested-template></div>
>     </template>
> </template>
> Script template:
> <script type=template>
>     <div id=foo class=bar></div>
>     <script> something();<\/script>
>     <script type=template>
>          <div class=nested-template></div>
>     <\/script>
> </script>
I *really* don't like this. The escaped backslash is an eyesore and
error-prone. Hijacking an existing tag with extremely crufty semantics with
yet more semantics doesn't pay for itself at all, especially when you
consider the strange closing script tag.

> Pros:
> - Similar to the way many JS-implemented templating sches work today

I think this is actually a negative. It looks like what people are doing
today, but a seemingly arbitrary type triggers completely new behavior. As
a (popular) template engine author, I would prefer a clean-slate tag
(<template>) to trying to cram more semantics into the existing <script>
tag with new gotchas.

> - Can be polyfilled with full fidelity and no risk of content that's meant
> to be inert accidentally running

This is a relevant concern. I could imagine several polyfill-friendly
solutions that could be used without worsening the long-term ergonomics of
this feature (using existing constructs for escaping).

The nice thing about <template> is that it is a completely new construct,
so future features could be added without the need to forever look over our
shoulder at the (insane!) <script> tag.

> - Can be translated consistently and compatibly to the XHTML syntax of HTML

Is this a real concern?

> - Less new weirdness. You don't have to create a new construct that
> appears to have normal markup content, but puts it outside the document.

Who is "you" here? A completely new element is more of a trigger to
"authors" of new behavior than a new type in a <script tag>

> - Can be specified (and perhaps even implemented, at least at first)
> without having to modify the HTML parsing algorithm. In principle, you
> could specify this as a postprocessing step after parsing, where accessing
> .template for the first time would be responsible for reparsing the
> contents and creating the template DOM. In practice, browsers would
> eventually want to parse in a single pass for performance.

This is relevant but should be considered a tie-breaker after developer
ergonomics are considered. Implementation difficulty should not drive API

> Cons:
> - <script type=template> is slightly more verbose than <template>
> - Closing of nested scripts/templates requires some escaping
See above, but there are more cons.

> In my opinion, the advantages of the script template approach outweigh the
> disadvantages. I wanted to raise it for discussion on the list.

Yehuda Katz
(ph) 718.877.1325
Received on Tuesday, 30 October 2012 20:57:52 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:49 UTC