Re: [webcomponents] HTML Parsing and the <template> element

On Tue, Apr 24, 2012 at 9:11 AM, James Graham <jgraham@opera.com> wrote:
> On 04/24/2012 05:57 PM, Yuval Sadan wrote:
>> Placing contents as CDATA is an option. I personally think the <template/>
>> tag as proposed is adhoc to somebody's notion of how templates should work.
>> To avoid this I think they should be simpler. I am not seeing the added
>> advantage of having the client parse the contents upon encountering it:
>> there is no use for the contents before it is used programatically, and as
>> such it could be prepared on first use, via the DocumentFragment suggestion
>> mentioned earlier. Specifically, it's never considered to be part of the
>> document's semantic content. Perhaps I'm overlooking something here.
>
> That is actually quite a useful axis of distinction. If we want normal
> methods on the document like getElementsByClassName or getElementById to
> return elements in templates they obviously need to be parsed as actual
> elements in the DOM. If we don't it seems very unnatural to have them parsed
> as elements; making DOM Core methods, CSS selectors, etc. have some
> dependence on whether there is an element called <template> in the tree just
> seems like a recipe for pain.
>
> My feeling is that the elements in templates aren't like the other elements
> in the document and so we don't want the normal lookup/traversal methods on
> document to work on them.

I *believe* we don't want lookup methods to find the inert elements
inside of a template.  Traversal should still work, obviously - if you
ask for the children of a template node, you should get its actual
children, so you can manipulate them.

This distinction is why one possible approach (previously stated) is
to stuff the elements into a separate subtree, similar to the shadow
tree.  That might make the design somewhat cleaner, in that the lookup
methods can continue to just lookup in the "normal" DOM.

~TJ

~TJ

Received on Tuesday, 24 April 2012 16:49:08 UTC