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

FrameMuse left a comment (whatwg/dom#736)

> I really don't wanna create conflict but I really don't like the idea of:

What, we're discussing and finding right solution, keep telling any of your ideas, that's normal.

> Transparent from query selectors? Yes! - I mean naturally, since it's not an Element type.
Transparent from in childNodes? No, because it's a ChildNode in the DOM.
Filtered from children? Yes, because it's not an Element type.
Transparent in children, meaning children of fragment appear as if they are fragment's parent's children? No!

Sorry, really, but I had to use LLM for breaking this down since I was so confused with what where persists.

<details>
<summary>Breakdown</summary>

1. **"Transparent from query selectors? Yes! - I mean naturally, since it's not an Element type."**  
   - This means the proposed node won't interfere with CSS selectors like `nth-child`, because it's **not an `Element`**. CSS query selectors (`document.querySelector`, `querySelectorAll`) typically target `Element` nodes, so if this new persistent fragment is not an `Element`, it will naturally be ignored.

2. **"Transparent from in childNodes? No, because it's a ChildNode in the DOM."**  
   - Even though it doesn't interfere with selectors, it **does exist in the DOM as a `ChildNode`**. This means that if you use `.childNodes`, you **will** see this node in the list, just like how text nodes appear in `.childNodes` but not in `.children`.

3. **"Filtered from children? Yes, because it's not an Element type."**  
   - This reinforces the idea that it **won’t appear in `.children`** because `.children` only includes `Element` nodes (like `<div>`, `<span>`). Since this new node type is **not an `Element`**, `.children` will ignore it.

4. **"Transparent in children, meaning children of fragment appear as if they are fragment's parent's children? No!"**  
   - This is rejecting the idea that the fragment’s children should behave as if they belong directly to the parent of the fragment.  
   - In other words, if a `<div>` contains this persistent fragment, the children inside the fragment will **not** appear as direct children of the `<div>`.  
   - This is different from how a **DocumentFragment** works, which is typically used for grouping nodes without affecting the DOM tree.
</details>

I totally agree with that since IMO the point is NOT about iterating through an element that contains Persistent Fragment, but about having a reference to the node (`PersistentFragment`), which holds other nodes as if they would have a parent.

Which is useful for rearranging, moving, adding, deleting nodes without caring about where they are currently placed altogether (for example, if a node is disconnected, it can't be moved anyhow, but sometimes we really want to do that, which is solved by a large amount of self-made code to "manually" support that).

---

BTW, I think it should be called `NodeGroup` instead of `PersistentFragment`, this way it basically highlights its familiar nature from Figma, Photoshop and many other places it's used and implemented this way - A transparent folder.

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

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