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

[Rafael Weinstein]

On Fri, Nov 18, 2011 at 1:33 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Thu, Nov 17, 2011 at 11:21 AM, Adam Barth <w3c at adambarth.com> wrote:
>> 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.
>
> What is the advantage of this approach?
>
> Not being able to interact with the template normally seems like a
> pretty big downside for templating systems as you completely lose the
> ability to use the normal flow of interacting with your DOM if you
> want to modify the template for future instances. I.e. you can't
> simply use .getElementById to find an element inside the template in
> order to interact with it.

All other things achieved, I'm not sure I have a preference for having
template contents be direct descendants of the template vs in a
disconnected fragment that it owns.

The getElementById issue you mention is interesting. On the one hand,
you'd like to have gEBI and queryS* work with the contents of
templates, but at the same time you'd like the logic of your
application not to be confused by selectors that match inside template
content.

For example: Imagine you have a "dialog" that may need to be displayed
at some point. Your application logic attaches to it once it's
instantiated into the visible DOM by grabbing specific IDs. But if
getElementById matches elements inside the template, then you'll
likely get the inert elements that aren't live in the page (since
developers tend to put "prototype templates" at the top of the page.

What if document.getElementById() didn't match template contents, but
myTemplate.querySelector() matches *only* its contents? Now you can
clearly get what you want simply by executing the API call in the
right place.

>
> Implementation-wise I think making "normal" elements inert would be
> easier since you can keep all existing DOM and parsing infrastructure.
> All you need to do is to propagate an internal "isInert" flag any time
> an element is inserted into the DOM. Then pay attention to this flag
> in the situations where the spec says that inert elements behave
> differently from normal elements.
>
> / Jonas
>