Re: [webcomponents] More backward-compatible templates

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
design.


>
>
> 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