Re: [webcomponents] More backward-compatible templates

On Fri, Nov 2, 2012 at 1:23 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> 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?

Yes.  <xmp> is basically <![CDATA[...]]> for HTML.  Unlike <script>,
it only takes one tokenizer state.

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

Honestly, the </+script> thing seems pretty nutty.  At least with
<xmp>, you can avoid that nuttiness because no one is interested in
nesting <xmp> inside 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.

I'm not sure I fully understand what you have in mind, but I don't
that works particularly well in XHTML because you can't nest CDATA
sections.  Recall that using inline scripts in XHTML requires
enclosing the contents of the script tag in a CDATA section:

http://lachy.id.au/log/2006/11/xhtml-script

If you plan to use CDATA for the entire template, then authors won't
be able to use inline script tags inside their templates.

Adam

Received on Friday, 2 November 2012 20:42:22 UTC