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

Re: [webcomponents] More backward-compatible templates

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 02 Nov 2012 09:23:30 +0100
Cc: Anne van Kesteren <annevk@annevk.nl>, "public-webapps@w3.org WG" <public-webapps@w3.org>
Message-id: <D9DA4065-84EA-4AF6-A005-9004FBBDA731@apple.com>
To: Adam Barth <w3c@adambarth.com>

On Nov 1, 2012, at 3:14 PM, Adam Barth <w3c@adambarth.com> wrote:

> 
> Another approach we considered was to separate out the "hide from legacy user agents" and the "define a template" operations.  That approach pushes you towards a design like
> 
> <xmp>
>   <template>
>     <h1>Inbox</h1>
>     <template>
>       <h2>Folder</h2>
>     </template>
>   </template>
> </xmp>

I'm not sure offhand of the parsing behavior of <xmp>. Will it prevent the contents from being parsed as tags? A nice feature of this type of approach is that you could use <xmp> across the transition to get polyfillability, and stop using it once all browsers support <template>. A downside is that it doesn't give an obvious way to solve the XHTML problem. I suppose you could put <!CDATA> inside the <xmp> just as is done with <script>.

As you mentioned in your message, you could take this approach with <script> as an outermost inertness-only layer. This would make things simpler because you would need only one level of <script> nesting, and only for templates that contain an inline script. I am not sure if an inline script in a template is likely to be a common case.

<script inert>
  <template id=outer>
    <script>
         function f() { return x; }
    </+script>
    <h1>Inbox</h1>
    <template id=inner>
      <h2>Folder</h2>
      <script>
           function g() { return x; }
      </+script>
    </template>
  </template>
</script>

With this approach, you could change the <script inert> parsing model from what I described to textually substituting </+script> with </script> before parsing. That would solve the issue you identified with inconsistency between parsing nested templates vs outer templates.

This would still have the issue with 'x =  "</+script><img onerror=alert(1)>";', where if that content is textually substituted into a nested script inside a template, it may surprisingly prematurely close the script. Though I wonder - is textually substituting untrusted content into a <script> element inside a <template> a likely scenario? I thought the whole point of templates was to avoid textual substitution.

I think these outer inertness wrapper ideas are actually pretty promising, despite your concerns, if they are designed to be optional. They let you get good polyfillability in a simple way, and you can stop using them if you don't care about polyfill or live in the future world where all browsers you care about have native <template> support. They can also be used along with CDATA in XHTML indefinitely.

Regards,
Maciej
Received on Friday, 2 November 2012 08:24:09 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:55 GMT