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

On Fri, Nov 18, 2011 at 2:58 PM, Rafael Weinstein <rafaelw at chromium.org> wrote:
> 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.

Personally it seems to me that moving the elements out of the DOM such
that you can't find them using gEBI/querySelector/firstChild is more
surprising than useful.

It would basically reduce the feature to syntax sugar for setting
.innerHTML on an orphaned <div>. Is that really producing the best
solution for authors?

/ Jonas

Received on Friday, 18 November 2011 15:44:47 UTC