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

[Rafael Weinstein]

On Fri, Nov 18, 2011 at 2:47 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Fri, Nov 18, 2011 at 2:31 PM, Rafael Weinstein <rafaelw at chromium.org> wrote:
>> 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.
>
> I think putting things in the markup that then not show up in the DOM
> is very surprising behavior.
>
>> 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.
>
> If we think making getElementById not match template contents is the
> right behavior, then that's easy to do. But (as was once pointed out
> to me), if you don't want gEBI to match inside the template, then why
> put id's in there at all? Using gEBI to find things in template

Basically you'd like to say: these will be the connection points of
this DOM when it becomes live in the page. IDs & classes are still
useful for the reasons they are now. You'd like to declare them as a
part of the "prototype", but like everything else in the prototype,
they are "inert" until they are instantiated.

An analogy is classes & instances in classical inheritance. You can
think of the template as the "class" definition, but you only want
behavior (including matching IDs, className, etc...) from instances.

> instances seems shaky since I would imagine that they are often
> instantiated multiple times?

We'll, you'd use an ID for things that will only be instantiated once
(at a time) and className for things that can be instantiated
multiply.

>
> Not sure what behavior you're wanting to get with querySelector. It
> only returns nodes that are descendants of the context already. Is
> maybe the still-being-defined .findAll behavior what you want?

Yes. Sorry that was unclear.

What I should have said was that querySelector when called on
non-template elements doesn't consider the contents of template
element. I.e. document.querySelectorAll() won't ever return inert
elements.

>
> / Jonas
>