On Tue, Oct 30, 2012 at 6:58 AM, Maciej Stachowiak <[email protected]> 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>
>
> 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.
I'm not sure I understand the escaping rules. Will all \ characters
need to be escaped as well?
How would multiply nested templates work?
<script type=template>
<h1>Inbox</h1>
<script type=template>
<h2>Folder i</h2>
<script type=template>
<h3>Email i</h3>
<script type=template>
<h4>Recipient i</h4>
<\\\\/script>
<\\/script>
<\/script>
</script>
It seems like the number of backslashes might grow exponentially...
Adam
