W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 24 Apr 2012 09:48:15 -0700
Message-ID: <CAAWBYDAGBi+FTg92js5VSTspQNWZTjdu2BiLa0aM-VHsThOKJg@mail.gmail.com>
To: James Graham <jgraham@opera.com>
Cc: public-webapps@w3.org
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.


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

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 13:55:50 UTC