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

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
instances seems shaky since I would imagine that they are often
instantiated multiple times?

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?

/ Jonas

Received on Friday, 18 November 2011 14:47:23 UTC