You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Upstream Shadow DOM spec to DOM/HTML Standard #377
SD section 2 could probably be moved into a subsection of DOM section 2
We'd probably create a new top-level section in DOM for shadow DOM. Maybe after "nodes". Maybe at the end.
SD sections 3 and 4 would move into the new top-level section.
SD section 5 would need some work. It needs to be integrated into DOM section 3.
"In each algorithm in this section, the Window must be considered as if it were the parent node of the Document so that the Window also receives an event." I am pretty sure HTML has a similar sentence, but I cannot find it easily...
UI Events, Touch Events, and HTML will need patches for shadow DOM 5.5-5.9
SD section 6 mostly gets upstreamed into HTML, some in Editing maybe.
SD section 7 goes into HTML, creating several new element categories for 7.1, and changing the processing algorithms as in 7.2.
SD section 8 goes into the new DOM top-level section on shadow DOMs
Some of the interface members on ShadowRoot need to go into other specs as partial interface definitions: activeElement and styleShets in HTML, element(s)FromPoint in CSSOM, innerHTML in DOM P&S, a few others... I think only host is left, actually.
I guess the definition of HTMLSlotElement and assignedSlot go in the HTML spec?
The blocklist of elements you cannot attachShadow too goes in HTML, or maybe becomes a DOM concept which HTML references.
SD section 9 goes into a subsection of the new DOM top-level section on shadow DOMs
We should check with @annevk, but I would be OK with gradually moving over pieces, leaving pointers from the current spec into their new destinations. The trick is figuring out what are good chunks of work to do that in. For example, we could move over the HTMLSlotElement and assignedSlot stuff in one chunk and have it reference the shadow DOM spec until it's fully integrated. We could move over the conceptual stuff in another chunk. Etc.
I think a good place to start would be the "in a document" versus "in a x document" checks in the HTML standard. That is once the pieces that is actually biting implementers. I forgot what we decided on for x.
Isn't the problem with "deep" that if you have a closed shadow tree those nodes would be excluded, as is the case with deepPath? Would it not be "composed"?
So far, I do not feel any trouble by using the term of "deep" in the Shadow DOM spec.
When I have to consider a closed shadow tree, I am using "unclosed node" or "unclosed tree" in defining the behavior of a closed tree. That seems successful, so far. I do not have any trouble.
"composed" might be confusing because the Shadow DOM spec has a well defined concept of "composed tree". "in a document deeply" and "in a composed tree" are different concept.
But, I am fine with using composed here because it sounds more intuitive, I think.
Thus, the candidates would be:
in a composed document
It might be confusing, due to the existing concept of composed tree. We might want to rename composed tree to something else, e.g. flattened tree, if we use "in a composed document" here.
So you are saying that deepPath uses the deep document, restricted to unclosed nodes?
I don't understand what the conceptual difference would be between "composed document" and "deep document" if deep document was not restricted to unclosed nodes. Which nodes would be in the former that are not in the latter? Or vice versa?
So you are saying that deepPath uses the deep document, restricted to unclosed nodes?
Basically, yes. (Though the spec does not use the term of "deep document")
There is no concept of "deep document" nor "composed document" in the spec.
The term of "in a composed document" is born in this thread and I meant we can use this new term as a replacement of "in a document deeply", if we want to avoid the term of "deep"
There are concepts of "tree of trees", "in a document deeply" and "composed tree" in the Shadow DOM spec. Those are well defined terms.
I am thinking that we can replace existing terms with more understandable terms:
"Tree of trees whose root tree is a document tree" => "composed document"
"in a document deeply" => "in a composed document"
"composed tree" => We might want to rename this to something else.
Note that "deepPath()" is only web-exposed API which uses the term of "deep". I am not sure how we should rename this or keep this as is.
My thinking with respect to the "deep" terminology was that it would be exactly like "composed", but restricted to "unclosed" nodes.
So most standards would operate on "composed documents", but APIs would be restricted to either "documents" or "deep documents", depending on the use case.
There was also the case of nodes that would not end up in the composed tree and how to address them. I don't think we had a solution for that.
How about "in a connected tree scope" where "tree scope" refers to either a Document or a shadow root which is a node's ancestor, and "connected" means the tree scope is either a document or its host is "in a connected tree scope".
If we reserve the "deep" terminology for this purpose, "deep child" or other similar terminologies should bee renamed to something, such as "composed child" ?
So most standards would operate on "composed documents", but APIs would be restricted to either "documents" or "deep documents", depending on the use case.
I am fine with this idea, basically. From my experience, most standards could operate on "a composed document". It's rare case that APIs would be restricted to "deep documents".
There was also the case of nodes that would not end up in the composed tree and how to address them. I don't think we had a solution for that.
"connected" would mean it's in the document or your shadow root's host is in the document regardless of whether any of shadow root inside which you reside is closed or not. So I think it corresponds to "composed" in your terminology.
If we can agree that we use "in a composed document", let me do a batch internal renaming refactoring in the Shadow DOM spec as follows:
a composed document: The new term, which is equivalent to "Tree of trees whose root tree is a document tree"
in a composed document: This is exactly equivalent to "In a document deeply"
deep XXX: => Will be renamed to composed XXX
composed XXX: => Will be renamed to flat XXX
This internal renaming does not affect any web-facing APIs.
I prefer "in a composed document" because it is short, relatively. "Shortness" is good here because it is expected that the term would appear in many places.
I am trying to upstream Shadow DOM into DOM/HTML to confirm that it can be integrated with DOM/HTML properly. The reason I could not maintain W3C Shadow DOM specification to reflect the latest change which is happening in DOM/HTML Standard is my bandwidth and its difficulty. It is difficult to pick up necessary parts nicely with a clear separation.
Let me try to spend my time on it, but I would also welcome contributions. If someone could work on downstreaming to W3C Shadow DOM specification from DOM/HTML Standard, it would be greatly appreciated.
I'm afraid that we have to copy almost all of "3. Events" and "4. Nodes" section, as is, from https://dom.spec.whatwg.org/, at least.
It might be confusing, but such is the price of peace! We (the Chrome team) feel deeply grateful to our colleagues at Microsoft (and other places) who have worked with all of us to keep Web Components on track. Part of the agreement that has allowed them to participate is that we maintain a version of this spec which can be run through the W3C process inside of WPWG. That means we'll carry the patch. More work, perhaps confusing, but necessary.
Hmm, I forgot to add retargeting process there. :(
Regarding w3c/DOM-Parsing#21, this was not fixed. I remember that we had a discussion about whether we should add innerHTML to DocumentFragment, rather than ShadowRoot, or not. However, I guess that was not solved due to the lack of follow-up.
Should we perhaps create a new tracking issue for all these items so we have a clean slate for all upstream work?
Yes, that would be great. Recently, I couldn't spend much time on upstreaming tasks. Please feel free to create a new tracking issue.
I remember that we had a discussion about whether we should add innerHTML to DocumentFragment, rather than ShadowRoot, or not.
We decided not to do this, since DocumentFragment doesn't always have a host like ShadowRoot does. This makes the "context node" question for the HTML parser much more complicated.
Activity
domenic commentedon Feb 2, 2016
I took a quick look.
ShadowRootneed to go into other specs as partial interface definitions: activeElement and styleShets in HTML, element(s)FromPoint in CSSOM, innerHTML in DOM P&S, a few others... I think only host is left, actually.We should check with @annevk, but I would be OK with gradually moving over pieces, leaving pointers from the current spec into their new destinations. The trick is figuring out what are good chunks of work to do that in. For example, we could move over the HTMLSlotElement and assignedSlot stuff in one chunk and have it reference the shadow DOM spec until it's fully integrated. We could move over the conceptual stuff in another chunk. Etc.
annevk commentedon Feb 3, 2016
I think a good place to start would be the "in a document" versus "in a x document" checks in the HTML standard. That is once the pieces that is actually biting implementers. I forgot what we decided on for x.
I think it's a good idea to do things in pieces.
hayatoito commentedon Feb 3, 2016
As far as I know, for x, there are several candidates:
However, in #362, I proposed connectedToDocument / disconnectedFromDocument.
The pros of
in a document deeplyis that it can be used as a replacement of both in a document and inserted into a document / removed from a document.e.g.
But if we use
connected to a document, it might be confusing?e.g.
annevk commentedon Feb 3, 2016
Isn't the problem with "deep" that if you have a closed shadow tree those nodes would be excluded, as is the case with
deepPath? Would it not be "composed"?hayatoito commentedon Feb 3, 2016
So far, I do not feel any trouble by using the term of "deep" in the Shadow DOM spec.
When I have to consider a closed shadow tree, I am using "unclosed node" or "unclosed tree" in defining the behavior of a closed tree. That seems successful, so far. I do not have any trouble.
"composed" might be confusing because the Shadow DOM spec has a well defined concept of "composed tree". "in a document deeply" and "in a composed tree" are different concept.
But, I am fine with using composed here because it sounds more intuitive, I think.
Thus, the candidates would be:
in a composed document
It might be confusing, due to the existing concept of composed tree. We might want to rename composed tree to something else, e.g. flattened tree, if we use "in a composed document" here.
in a document deeply.
connected to a document
annevk commentedon Feb 3, 2016
So you are saying that
deepPathuses the deep document, restricted to unclosed nodes?I don't understand what the conceptual difference would be between "composed document" and "deep document" if deep document was not restricted to unclosed nodes. Which nodes would be in the former that are not in the latter? Or vice versa?
hayatoito commentedon Feb 3, 2016
Sorry for confusing.
Basically, yes. (Though the spec does not use the term of "deep document")
I am thinking that we can replace existing terms with more understandable terms:
Note that "deepPath()" is only web-exposed API which uses the term of "deep". I am not sure how we should rename this or keep this as is.
annevk commentedon Feb 3, 2016
My thinking with respect to the "deep" terminology was that it would be exactly like "composed", but restricted to "unclosed" nodes.
So most standards would operate on "composed documents", but APIs would be restricted to either "documents" or "deep documents", depending on the use case.
There was also the case of nodes that would not end up in the composed tree and how to address them. I don't think we had a solution for that.
rniwa commentedon Feb 4, 2016
How about "in a connected tree scope" where "tree scope" refers to either a Document or a shadow root which is a node's ancestor, and "connected" means the tree scope is either a document or its host is "in a connected tree scope".
hayatoito commentedon Feb 4, 2016
I'm okay to use the deep terminology in this sense. But the current Shadow DOM spec does not follow this rule, e.g. "deep child": http://w3c.github.io/webcomponents/spec/shadow/#dfn-deep-child
If we reserve the "deep" terminology for this purpose, "deep child" or other similar terminologies should bee renamed to something, such as "composed child" ?
I am fine with this idea, basically. From my experience, most standards could operate on "a composed document". It's rare case that APIs would be restricted to "deep documents".
"in a composed document, but not in a document composed tree" could work, I think.
http://w3c.github.io/webcomponents/spec/shadow/#dfn-document-composed-tree
It this is too long, we have to invent yet another terminology as an alias for this long condition.
annevk commentedon Feb 4, 2016
@hayatoito yeah, "deep child" would have to become "composed child".
@rniwa is "connected" a replacement term for "composed" or "deep" (with "deep" meaning "composed" excluding "closed")?
rniwa commentedon Feb 4, 2016
"connected" would mean it's in the document or your shadow root's host is in the document regardless of whether any of shadow root inside which you reside is closed or not. So I think it corresponds to "composed" in your terminology.
hayatoito commentedon Feb 5, 2016
If we can agree that we use "in a composed document", let me do a batch internal renaming refactoring in the Shadow DOM spec as follows:
This internal renaming does not affect any web-facing APIs.
I prefer "in a composed document" because it is short, relatively. "Shortness" is good here because it is expected that the term would appear in many places.
Does it sound good?
24 remaining items
[#377] Add warning messages
hayatoito commentedon Sep 30, 2016
The status update:
The remainings are Section 6, 7 and 8.
hayatoito commentedon Oct 6, 2016
Let me clarify my upstreaming plan:
I am trying to upstream Shadow DOM into DOM/HTML to confirm that it can be integrated with DOM/HTML properly. The reason I could not maintain W3C Shadow DOM specification to reflect the latest change which is happening in DOM/HTML Standard is my bandwidth and its difficulty. It is difficult to pick up necessary parts nicely with a clear separation.
Let me try to spend my time on it, but I would also welcome contributions. If someone could work on downstreaming to W3C Shadow DOM specification from DOM/HTML Standard, it would be greatly appreciated.
I'm afraid that we have to copy almost all of "3. Events" and "4. Nodes" section, as is, from https://dom.spec.whatwg.org/, at least.
annevk commentedon Oct 6, 2016
Why would we maintain a copy? That seems way confusing.
slightlyoff commentedon Oct 11, 2016
Hey @annevk:
It might be confusing, but such is the price of peace! We (the Chrome team) feel deeply grateful to our colleagues at Microsoft (and other places) who have worked with all of us to keep Web Components on track. Part of the agreement that has allowed them to participate is that we maintain a version of this spec which can be run through the W3C process inside of WPWG. That means we'll carry the patch. More work, perhaps confusing, but necessary.
Thanks for understanding.
Downstream from the WHATWG DOM Standard (#377)
Downstream "ShadowRoot interface" from DOM Standard (#377)
Remove duplicated sections (#377)
annevk commentedon Sep 4, 2017
@hayatoito do you have a pointer for the Touch Events work as I don't find anything about shadow trees in https://w3c.github.io/touch-events/? Same for UI Events actually, nothing about shadow trees in https://w3c.github.io/uievents/. I'm also missing a pointer to w3c/DOM-Parsing#21 for
innerHTML.https://github.com/whatwg/html/labels/topic%3A%20shadow is another list of outstanding issues.
Should we perhaps create a new tracking issue for all these items so we have a clean slate for all upstream work?
annevk commentedon Sep 4, 2017
It seems we also have #495 which attempts to track something similar perhaps? @rniwa thoughts on where to track all these issues?
hayatoito commentedon Sep 5, 2017
Regarding TouchEvents, it looks what I have done is to make TouchEvents 'composed' events, and add event retargeting process.
Regarding UIEvents, it looks what I have done is to make some UIEvents 'composed' events.
Hmm, I forgot to add retargeting process there. :(
Regarding w3c/DOM-Parsing#21, this was not fixed. I remember that we had a discussion about whether we should add innerHTML to DocumentFragment, rather than ShadowRoot, or not. However, I guess that was not solved due to the lack of follow-up.
Yes, that would be great. Recently, I couldn't spend much time on upstreaming tasks. Please feel free to create a new tracking issue.
annevk commentedon Sep 5, 2017
We decided not to do this, since
DocumentFragmentdoesn't always have a host likeShadowRootdoes. This makes the "context node" question for the HTML parser much more complicated.annevk commentedon Sep 5, 2017
Closing in favor of #661.
Update README.md (update bug number and its link)