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

justinfagnani left a comment (whatwg/dom#736)

> The `NodeGroup` seems to partially participate in a DOM tree in a new way. I wonder if this breaks invariants assumed in the spec or leads to any unexpected behavior. Generally in DOM a node is a child of its parent. Correct me if I'm wrong, but...
> 
> * a `NodeGroup` is not a child of its parent
> * the parent of a child of a `NodeGroup` is not the `NodeGroup` (or sometimes is?)
> * a child of a `NodeGroup` is also a child of a `NodeGroups`'s parent

This is an important point to consider. In essence a node could have two parents: a group and the parent of the group. Only one could be representable in the tree as the `parentNode`, and that would have to be the container, not the group, or all kinds of traversal code would break.

This novel tree structure will lead to inconsistencies like this:

```ts
const container = document.createElement('div');
const group = document.createNodeGroup();
container.append(group);

const child = document.createElement('span');
group.append(child);
child.parentNode === group; // false - Is this confusing? In any other DocumentFragment or ParentNode it would be true.
```

Put another way, this is no longer always true:
```ts
parent.children[0].parentNode === parent;
```

Now maybe this is ok because DocumentFragment is already kind of weird by emptying its children into a container it's appended into, and never having a parent itself, but it definitely breaks some assumptions you could previously make about nodes.

This does make me wish for solution that's more consistent with current DOM invariants. This is one reason that ChildPart acted more like a Range than a Node. You don't have the same tree expectations from Range.

I think that ideally, if this thing is a Node at all, we really would want a very element-type node that lives in the tree - elements have nearly all of the qualities we want except for wrt CSS.

I know that may be impossible now, but it would be really nice if we could introduce a new element that was allowed anywhere like a script supporting element, but that renders, so also with a transparent content model, and if there were a new CSS `display` value similar to `contents` that also hid the element from combinators like `>` and pseudo-classes like `:nth-child()`. A practically invisible element, named like `<g>` or something. It would solve serialization naturally.

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

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