Shadow DOM and "insertion steps" / "removing steps"

[annevk]

The Shadow DOM specification needs to "monkey patch" DOM Standard's "insert" and "remove" algorithms to account for shadow trees.

If nodes in shadow trees are never notified they have been inserted or removed, there are no hooks for other standards to define how they should behave there.

[annevk]

I have done this now in the DOM Standard directly. See:

• https://dom.spec.whatwg.org/#concept-node-insert-ext
• https://dom.spec.whatwg.org/#concept-node-remove-ext
• https://dom.spec.whatwg.org/#interface-shadowroot (has new tree definitions that account for shadow roots; perhaps I should replace "shadow-root-including" with "composed" though, although less explicit it seems easier to read)

Feedback appreciated.

[hayatoito]

Looks good. Thank you.

BTW, I am totally okay to have host-including ancestor, shadow-root-including descendant, shadow-host-including inclusive ancestor and so on, as a replacement of composed-xxx.

Do you have any feeling when you used these terms in DOM Standard? If you felt good, I think that's a good news and we can use these terminologies.

[annevk]

I think one problem is that I have used "shadow-root-including" and not "shadow-host-including". Maybe I should just say "shadow-including". That might make the most sense.

[annevk]

Thanks for the review. If someone still finds the terms unacceptable please raise an issue.

[hayatoito]

Either is okay to me. I just thought you tried to make them more explicit.

• shadow-host-including ancestor
• shadow-root-including descendant

I thought this pair is very intuitive.

[annevk]

I see. Okay, if this comes up again I'll switch back to the longer prefixes.