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

Received on Wednesday, 31 October 2012 18:14:46 UTC