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>
     var s = "I&quot;m going...";
  Some things go here.

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">
         var s = "I'm going...";
   var iframe = document.getElementById('a1');

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>

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

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>
    <p>The future!</p>

is the same as:

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

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

What do you think Henri?

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:37 UTC