Re: [whatwg/dom] Proposal: a DocumentFragment whose nodes do not get removed once inserted (#736)

robbiespeed left a comment (whatwg/dom#736)

> NodeGroup IS a parent, since you mentioned it is purely a Node with children, which makes a Parentnode, which as you mentioned a strong benefit for this proposal (it reuses existing interfaces).

It's **like** a ParentNode in that it has children, but that does not mean it needs to be a ParentNode.

Having NodeGroup children `parentNode` prop always refer back to the NodeGroup would break DOM walking code, ex: some event listener walking up the DOM expecting `parentNode` to be Elements. And it would be especially weird to have walking `childNodes` produce a different ancestry than walking `parentNode`.

> it implements a variant of ParentNode interface which delegates to the actual parent or its internal fragment (until live) all the things.

@WebReflection I don't mind this, so when not live the `parentNode` of the grouped nodes would be something like a internal DocumentFragment, and when live it would be a element that the group was rendered into? What happens when the group is rendered into another group, Document Fragment, or orphaned element? I would expect that `parentNode` of any grouped nodes is basically recursive until it either hits a orphaned group at the root (internal fragment) or the first Element/DocumentFragment.

It seems this method would remove the option of overlapping groups like you can have with ranges, but that hardly seems like a useful feature. It would also mean that attempting to group nodes which are already part of a group would need to error or remove the nodes from the old group. My vote would be to throw an error, otherwise 3rd party libs or extensions might break groups used in rendering by attempting to group them themselves.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/736#issuecomment-2762585571
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/736/2762585571@github.com>

Received on Friday, 28 March 2025 21:32:55 UTC