- From: Anne van Kesteren <notifications@github.com>
- Date: Tue, 16 Feb 2016 06:47:11 -0800
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/382/184709196@github.com>
I guess it makes sense to support that given that we also support event dispatch in such cases. However, I think we should try to iterate on the terminology some more. I think it would be better to define a component tree as a tree whose root node is either a Document object or a ShadowRoot object (i.e., whose root node implements the Component mixin). What you call component tree today is no different from "node tree", which makes it less of a useful term. (And instead of defining fragment tree say the algorithm operates on a node tree and that it doesn't have to be a component tree necessarily.) I'm a little confused with what the specification calls "composed tree" today. When we talked about "composed tree" elsewhere I had what the specification calls the "flat tree" in mind. Is the "composed tree" language really necessary vs just talking about a node tree's hosted shadow trees or some such? I'm probably missing something significant here, but it seems variants of what the specification calls "flat tree" is what we'll need to define most features. --- Reply to this email directly or view it on GitHub: https://github.com/w3c/webcomponents/issues/382#issuecomment-184709196
Received on Tuesday, 16 February 2016 14:48:01 UTC