Figure out terminology for Shadow DOM that everyone agrees on #382
Comments
It should work, although the spec does not mention it clearly. That is the reason I can not define the terminology of component tree simply as either a document tree or shadow tree. I had to introduce the terminology of fragment tree and let the definition of component tree include a fragment tree as workaround. A fragment tree is a node tree whose root node is, such as, the result of "document.createElement() but never inserted into a document". Unfortunately, the spec had been unclear on this kind of topic. So I have introduced these terminologies recently. The intention of the current spec is: Shadow DOM should work even for a composed tree (of component trees) whose root tree is not a document tree. e.g.
In fact, Blink supports this. AFAIR, there is no public discussion on this topic. Thus, it might be worth discussing that we really want to support this or not. A use case is not clear to me. @esprehn, @sorvell, do you know a use case or the reason why we need to calculate distribution for such a composed tree whose root tree is not a document tree? |
|
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. |
Yeah, that's true. Unfortunately, "component tree" become the same meaning of "node tree" at this commit: I was aware of this fact when committing this change, however, I had no better idea and do not want to replace all "component tree" with "node tree" at that time.
Yes. That's painful. Actually, my colleague objected when I tried to re-use the "composed tree" as other meaning because it might be confusing. But I thought that we had to do it before upstreaming. I wanted to get rid of ugly terminology of "tree of trees", so I decided to re-use "composed tree" as "tree of trees" because "composed tree" became a good candidate to replace "tree of trees", give that we started to use "composed XXX", such as "composed child", "composed parent", to represent a relationship within a tree of trees, where distribution is not involved at all.
I do not expect that we have to use the "composed tree" frequently. In most cases, we can simply use "in a composed document" or "inserted into a composed document". That is enough and will cover the most cases. We might get rid of this terminology, "composed tree", but this is very useful concept to define relevant algorithms. I do not care how we call it. "tree of trees", "composed tree" or something else, anything is okay to me. But I just needed a terminology to represent "tree of trees" so far.
Good question, however, I am not sure which is used frequently: "composed XXX" vs "flat XXX".
Hmm. I can not tell which is used frequently. Do you want to use "composed XXX" as frequent words? |
|
Thank you for explaining it once more. Much appreciated. Yeah, "composed" makes sense for So composed tree is a node tree including its hosted composed trees. The hosted trees of a composed tree will always be shadow trees. (You can imagine an even bigger tree that includes A flat tree is the result of distributing the composed tree. I'd like to have clearer terms, but I'm having a hard time coming up with them. |
|
How about "slotted tree" instead of "composed tree"? "flattened tree" seems fine. |
|
@rniwa "slotted" sounds like distribution already happened, whereas "composed tree" in the specification refers to a node tree and the shadow trees it hosts (recursively). |
|
@annevk : "distribution" is distinct from "slotted" in that |
|
@rniwa given |
|
@annevk : oh I see, it would be a bit confusing in that case. Yeah, "connected" sounds good to me. |
|
I do not worry much about the naming. These terminologies are used internally and we can rename them anytime without impacting web-facing APIs. On the other hand, in term of interoperability, we should have a rough consensus on the following:
Do we agree on this? See also #356 and #384 (comment) . @sorvell, Polymer depends on this assumption, doesn't it? |
|
This also affects "slotchange" event. #288 If distribution should work for such a disconnected shadow tree, we have to decide whether slotchange events should be supported or not for such a shadow tree. |
|
I think it would be more consistent with the DOM if it did work. The DOM generally doesn't care what the root is for any particular feature to work or not work. |
|
I just read the event path algorithm and it appears #382 (comment) is wrong. Events no longer use the flat tree (they did before, right?). So now if you have |
|
It go though the shadow tree. I mean the The basic idea of the event path has not changed, I think. The event path is almost the same to ancestor chains in a flat tree. The only difference is that event path also includes a shadow root and a slot. The reason we can not use a flat tree as is is that we should include a shadow root in the event path. |
I got it. Thank you. |
|
Ah yes it does. I was reading the algorithm incorrectly. "assigned" should probably be a term that is defined in some way and linked. |
FWIW, I would like us to care about it and reach agreement. It helps tremendously in communication if we are all on the same page and it will make merging Shadow DOM into other standards much easier if they all use the same terminology that we know will no longer change. |
|
Yeah, I agree. Let me think about it again. Since it looks Shadow DOM should work in a shadow tree which is disconnected from a document, my preference is:
|
|
In general, I am fan of the current naming. The mental model behind the scene is:
|
|
As @rniwa keeps pointing out there's also a "slotted tree", no? I think it's a little confusing that we call it a tree of trees. You'd expect in such a scenario that e.g., a child represents a whole tree and not a node. A "composed child" however is defined to be a node. So either we define some kind of transformation node tree -> composed tree whereby it would no longer be a tree of trees, just a fuller node tree, or we make it a tree of trees. @rniwa also objected to "component tree" but it seems like we can get away with just making that "node tree" almost everywhere. |
|
Or we stop pretending that "composed tree" is a thing and define needed terminology upon a "node tree" that digs into the shadow trees. |
|
@rniwa @hayatoito ping. |
|
It is not a good idea to use a Any terminology which is related to distribution should not be involved there. We might add yet another slot-like element in the future. Thus, a I agree that the usage of current "composed XXX" is confusing. Let me think further how we can avoid this confusion. Hmm. |
|
I did not mean to say that "slotted tree" would be a replacement, just that it was something that wasn't mentioned in your list that we maybe need to account for? I've been working on some other things since this was not moving forward. I'll try to make some time to come up with a proposal. |
|
I really dislike the name "component tree". I would suggest removing it in favor of "document tree" or "node tree". |
annevk
changed the title
|
Yes, shadow DOM should work in a disconnected node tree. |
ha. document tree or node tree don't hint anything in the name that they might deal with shadow dom too, so I'm rather strongly against using them in cases when there are nodes both in shadow DOM and in light DOM. And yes, shadow DOM shouldn't care about whether the host is in document or not. |
@smaug---- , could you help me to understand the point? |
|
He's opposed to use the term node tree as something that is larger than what node tree is today (e.g., something that would include shadow hosts or hosted shadow trees). Using node tree for a tree where the root happens to be a shadow root is fine. |
|
Does it mean we can use a node tree only if it is a leaf (tree) in a composed tree? e.g. B, C, E and F in http://w3c.github.io/webcomponents/spec/shadow/#example-composed-tree-of-component-trees Sorry, I'm still confused... However, I think we will not extend the meaning of the node tree here. Even if a node tree A includes a node B which is a shadow host, A still remains to be a node tree by the definition. A node tree A does not include a node in a shadow tree which B hosts. Thus, one node tree never includes both a light DOM and a shadow DOM. |
|
Indeed, a node tree can be used for any tree consisting of just nodes. That is what @smaug---- meant too. |
|
Yeah, that matches my understanding. It looks I misunderstood what @smaug---- meant. Sorry for the confusion. Thus, is everything okay? Let me use a node tree in the spec, replacing a component tree, as a first step. |
|
I think everyone agrees that shadow trees should work irrespective of the shadow-host-including inclusive ancestor being document (i.e., in disconnected trees as you call them). But I don't think we have a plan for the terminology yet. |
|
Why don't we always say "document tree or shadow tree"? There is no terminology more clear than that, and if anyone comes up with a better name, we can deploy it later. |
Shadow DOM should work for a node tree which is neither document tree nor shadow tree, which we just agreed on??? |
|
@rniwa I'm not sure I follow how that can be used. HTML has "in a document" now. Meaning a node's ancestor is document. We need something like that, meaning a node's shadow-host-including inclusive ancestor is document. With shadow-host-including inclusive ancestor defined as a variant on https://dom.spec.whatwg.org/#concept-tree-host-including-inclusive-ancestor with hosts restricted to shadow roots. We also need something where we apply an algorithm to a node tree and derive a flat tree. And that algorithm should maybe assert the node tree is not itself hosted. We might need something for slotted too, though maybe since slotted is only exposed in a few places that does not need much extra other than algorithms for use by those methods. |
Ops! I do not know this concept. Was this introduced for |
|
It was introduced for the |
I don't follow. A node tree's root node is either a Document, ShadowRoot, or something else, right? It's a shadow tree if the root node is a shadow tree, and document tree if its root node is a Document.
Didn't we say we use the term |
Yeah, a couple of facts:
e.g. The result of createElement('div'). That is a node tree that has only one node. We can not call it a document tree nor a shadow tree. This node tree itself is the root tree of a composed tree, which has only one node tree, by definition. When we attach a shadow tree to this node, Shadow DOM should work in this composed tree, whose root tree is not a document tree. Thus, "a document tree or a shadow tree" might not cover this case... |
|
I've removed Thus, the followings are remaining contentious bits, right?
Other ideas so far:
Is there anything else? Note that the spec has already defined the following terminologies, which we can use:
|
|
I was trying to figure out how as e.g., an I'm still trying to figure out what the best primitive is to have there (if we need a distinct notification next to parent change or if ancestor change is sufficient for all nodes, basically, I guess it doesn't matter much). If we add shadow trees to the mix though that ancestor becomes a shadow-host-including inclusive ancestor (or a inclusive composed ancestor per current Shadow DOM terminology). Is that still okay? If the host element was inserted into a closed shadow tree (whose shadow-host-including inclusive ancestor was a document), what kind of events would be fired on the custom elements inside host element's shadow tree? We can't really tell them the ancestor that got inserted since that would leak the closed shadow tree. @domenic have you looked at these events yet for custom elements? (Maybe this should be a distinct issue. On the other hand, I'm just trying to figure out what all the various primitives are since they're not really documented at the moment. And hopefully once we have the primitives we can figure out suitable terminology for them.) |
|
I think this is slowly being resolved by integration with the DOM Standard (and soon HTML Standard). If anyone has any concerns about that let me know. |
|
Now, the spec is not using the composed {parent/child/ancestor/descendant} terminologies. As the next step, I am now trying to avoid terminologies which are related to "composed tree of node trees". I am now rewriting the spec so that we do not need to use "composed tree". |
|
I successfully updated the spec so that it does not depend on a concept of composed tree of node trees in normative sections. I resolved almost all issues of the terminologies around:
I think we can close this issue now. |
|
If someone asks me what a "flat tree" or "composed tree" is when I am describing Shadow DOM to them, where should I link them to? This thread is one of the top results on Google, at least for me (we know Google has bias on a per user basis so maybe the result is more likely to show up for me than someone else). Even in an incognito window, this thread is still the third result (for me, while in Oakland, CA). The original document, for example https://www.w3.org/TR/2015/WD-shadow-dom-20151006/, was nice because it explained the topic more clearly and with visual diagrams. But now, those documents are "outdated", and clicking forward to the new documents leads to a place that is far less helpful, does not include concise descriptions of the concepts, and does not include tree diagrams. It seems to be a regression in terms of helping people understand the concepts (like the original document did). It seems virtually impossible for (especially new) people to learn (from official documents) what ShadowDOM is, and how the tree works and how it renders (f.e. rendering from the "flat tree"). Have I missed another document somewhere? |
It's not clear to me there is a difference.
Also, does Shadow DOM work without there being a document? There is a lot of terminology around there not being a document at the root. Is that to account for shadow trees in something created through
document.createElement()but never inserted? Will event dispatch there go through the shadow tree and such?The text was updated successfully, but these errors were encountered: