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

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

From: Rafael Weinstein <rafaelw@chromium.org>
Date: Thu, 17 Nov 2011 11:15:28 -0800
Message-ID: <CABMdHiSuzgUYo-E59wHmxgXxt47DwQz=G9N4wV=ZbK0LrtsPLQ@mail.gmail.com>

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

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:

  <span>Hello, world (at some point)</span>

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).

-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)

-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:15:28 UTC

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