W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

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

From: Elliott Sprehn <esprehn@gmail.com>
Date: Mon, 2 Jul 2012 17:35:41 -0700
Message-ID: <CAPJYB1jJdtRfkYgnroeUT4Nw+dy+X3mHKuz97c9UiSMi_nwMjQ@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: Rafael Weinstein <rafaelw@google.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Ian Hickson <ian@hixie.ch>, Dimitri Glazkov <dglazkov@chromium.org>, public-webapps <public-webapps@w3.org>, Adam Barth <w3c@adambarth.com>, Erik Arvidsson <arv@google.com>, Yehuda Katz <wycats@gmail.com>
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.


>  >> Besides, we'd need something like this for the XML case anyway if the
> >> position the spec takes is that it shies away from changing the
> >> correspondence between XML source and the DOM.
> >>
> >> ...
>

I've done a lot of thinking about this and it occured to me that perhaps we
should think about templates from a different perspective, more like a
natural extension of iframes.

Recently I wrote a test for Webkit and tried to use iframe @srcdoc:

<iframe sandbox="allow-same-origin" srcdoc='<p>
  <script>
     var s = "I&quot;m going...";
  </script>
  Some things go here.
</p>'>

but that wasn't nice because my editor couldn't syntax highlight it and I
had to escape quotes, so what I ended up writing was

<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 was much easier to read and maintain and didn't require escaping.

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.

However in the case of <template> this element is entirely new so we could
make this change.

If we think about template as an extension of <iframe sandbox> they have a
lot in common:

1) Template shouldn't run scripts and should behave similar to <iframe
sandbox="allow-same-origin">.

2) An iframe like this has it's children in a separate place
(contentDocument) like template has fragment.

So the spec changes become:

HTMLTemplateElement extends HTMLIFrameElement

@sandbox allows a new value "block-loading" to get the inertness property
of template

And finally we get the equivlanece:

<iframe sandbox="allow-same-origin block-loading" content-is-inside>
  <p>Hello World</p>
  &lt;template&gt;
    <p>The future!</p>
  &lt;/template&gt;
</template>

is the same as:

<template>
  <p>Hello World</p>
  <template>
    <p>The future!</p>
  </template>
</template>

We could even stop using the .fragment property and make it use
.contentDocument instead. For XML you can just write the full iframe
version.

What do you think Henri?

- E
Received on Tuesday, 3 July 2012 00:36:28 GMT

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