W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2011

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

From: Adam Barth <w3c@adambarth.com>
Date: Thu, 17 Nov 2011 11:21:17 -0800
Message-ID: <CAJE5ia9n7kjbyxh7q-bMhwNGsV1H3fEUgbXBBJTdU-zrK-tZQA@mail.gmail.com>
Another option is to tokenize the elements as usual, but put them into
a new document created for the <template> element (presumably using
the usual tree-building rules).  Because this document won't have a
browsing context, all the elements would be "inert", like they are for
documents created by XMLHttpRequest.  The site could access this
document via a templateDocument (or whatever) property on
HTMLTemplateElement.

Adam


On Thu, Nov 17, 2011 at 11:15 AM, Rafael Weinstein <rafaelw at chromium.org> wrote:
> Problem:
>
> Dynamic web pages often need to author and deliver fragments of DOM
> which *may* be used at some point during the page's lifetime, but have
> them be "inert" until they are needed.
>
> In this context, "inert" means not only that the fragment isn't
> rendered, but also that:
>
> -Resources don't load
> -Scripts & plugins don't run
> -Audio/Video don't play
> -Attributes aren't normalized
> -getElementById & querySelector don't match inert elements
> (etc)
>
>
> What are web pages doing now (all client-side templating libraries
> have *some* solution for this)?
>
> They hide these inert structures in various ways:
> -text literals within js files
> -hidden text areas
> -script tags with non-script file types
> -comment tags
> -elements marked as display: none
>
>
> Why isn't this good enough:
>
> All of these approaches either:
> -Force the treatment of the inert fragment as text which must be
> parsed and encourages the use of innerHTML (and often leads to XSS)
> -Or don't meet the requirements for "inert" listed above.
>
> In addition, because the approaches are non-standard, they interact
> badly with the HTML tool-chain and/or have encoding limitations
> (script does not allow "</script>", etc...).
>
>
> (Very hand-wavvy) Proposal:
>
> <template>
> ?<div>
> ?<span>Hello, world (at some point)</span>
> ?</div>
> </template>
>
> For parsing, the template element's contents are treated as HTML, but
> aren't subjected to normalization or placement/lifting rules.
>
> Big question: by what mechanism are these elements inert?
>
> One idea:
>
> Elements which are descendants of a template element have no default
> view (similar to elements in a document that does not have a view).
>
> Pro:
> -Elements are what their tagName suggests.
> -Their API is consistent between the inert state and the live state.
> -Inert elements are usable by simply placing them elsewhere in the DOM
> (by simply moving them to be descendants of a document)
>
> Con:
> -Will we need to spec the behavior of all elements while in this state?
>
> An alternate approach:
>
> The parsing of the template element's contents creates
> HTMLInertElements (or HTMLUnknownElements) which only have tagName &
> get/setAttribute. <template> gets a method called "instantiate()"
> which returns a DocumentFragment containing the corresponding elements
> made "live".
>
>
> Comments? Other options?
>
Received on Thursday, 17 November 2011 11:21:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:09 UTC