Re: [webcomponents] HTML Parsing and the <template> element

On Tue, Jul 3, 2012 at 3:35 AM, Elliott Sprehn <esprehn@gmail.com> wrote:
> On Fri, Jun 15, 2012 at 4:28 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
>>
>> ...
>>
>> >>
>> >> I think that would be preferable compared to opening the Pandora's box
>> >> of breaking the correspondence between the markup of the DOM tree.
>
> This already seems true for iframe seamless + @srcdoc.

The value of srcdoc ends up as an attribute value in the DOM, doesn't it?

> <iframe sandbox="allow-same-origin" id="a1">
>     <p>
>       <script>
>          var s = "I'm going...";
>       </script>
>     </p>
> </iframe>
> <script>
>    var iframe = document.getElementById('a1');
>    iframe.contentDocument.open();
>    iframe.contentDocument.write(iframe.textContent);
> </script>

This is similar to using <script type=something/new></script> for
templates that are just text nodes from the DOM POV.

> So it occured to me what I really want to write is:
>
> <iframe content-is-inside>
>     <p>Example</p>
> </iframe>
>
> The only down side here is that iframe is currently PCDATA so making such a
> change wouldn't be backwards compatible with existing content since you
> can't nest another <iframe> inside it.

For iframes, it wouldn't be more crazy to feed the child text node to
another parser than it is to feed an attribute value to another
parser. With two-level parsing, it would be even an advantage that
iframe is special in its content handling. As for avoiding two-level
parsing and instead of making the first parser directly generate the
child document without leaving the source as a text node inside the
iframe would a similar sort of change as wormhole templates.

For templates, there seems to be a desire to avoid the sort of
two-level parsing srcdoc uses.

> For XML you can just write the full iframe version.

It's not clear to me what you mean.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Sunday, 5 August 2012 14:12:29 UTC