On Tue, Apr 24, 2012 at 9:11 AM, James Graham <jgra...@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