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>
Pros:
- Similar to the way many JS-implemented templating sches work today
- Can be polyfilled with full fidelity and no risk of content that's meant to
be inert accidentally running
- Can be translated consistently and compatibly to the XHTML syntax of HTML
- 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.
- 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.
Cons:
- <script type=template> is slightly more verbose than <template>
- Closing of nested scripts/templates requires some escaping
In my opinion, the advantages of the script template approach outweigh the
disadvantages. I wanted to raise it for discussion on the list.
