[whatwg] Declarative Inert DOM (e.g. the <template> element)

[Rafael Weinstein]

On Thu, Nov 17, 2011 at 12:50 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Thu, Nov 17, 2011 at 11:15 AM, Rafael Weinstein <rafaelw at chromium.org> wrote:
>> For parsing, the template element's contents are treated as HTML, but
>> aren't subjected to normalization or placement/lifting rules.
>
> For the placement/lifting rules, we can ride on the coattails of the
> innerHTML parsing discussion, which wants to add a "null context"
> parsing mode to the HTML parser.
>
> What's the reasoning for not doing attribute normalization?  By that I
> assume you mean translating boolean attributes into having their name
> as their value?

Many inert declarations will contain text in content attributes which
represent future replacement instructions. E.g.

<input tabIndex="{{ foo.bar.tabIndex }}">

Note that I'm picking an arbitrary replacement syntax here. Different
template libraries or uses of inert DOM will have different syntax.
The key is that the inert DOM is parse-able as HTML, but that the
contents of attributes and text nodes are left alone while the
elements are in the inert state (kept verbatim in the attribute map)

I think it's an expectable trade-off for all uses that their
replacement syntax can't interfere with HTML parsing, as what they get
from this is quite a bit of convenience and safety.

>
>
>> Big question: by what mechanism are these elements inert?
>
> I like Adam's suggestion of a new document without a browsing context.
>  You can still move the elements into the active document and have
> them "just work", and all the other issues are taken care of "for
> free".

I think that would be a fine solution. When I discussed this with
various folks, that option came up as well, but some were concerned
that a document might too heavy weight.

Keep in mind that pages may have *many* <template> declarations. I'd
expect a sophisticated page/app to have template declarations the
hundreds if not thousands.

>
> ~TJ
>