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

WebReflection left a comment (whatwg/dom#736)

> From children[0]'s perspective, this is a new state that hasn't existed before. Maybe that ends up being totally fine, but I think we need to consider it carefully.

This is the part I don't understand:

  * `children[0]` has no notion of the group node and its state is exactly the same of any child element that was inside a fragment and then got appended elsewhere ... from `children[0]` perspective **nothing changes** ... it's always a children of something unless it gets removed from its parent, regardless if this is being a fragment, a living node on the DOM, or a group node ... so what is the concern, exactly there? A node can be inside another node or not ... what is the difference from everything we know already?
  * eventually that is "*weird*" only from the *GroupNode* point of view, not for its child nodes, but what is the *real-world* use case to perform such check and who has ever tracked `parentNode` which is not even possible via *MutationObserver*?
  * a *GroupNode* operates through its boundaries ... if having `children` that reflects those live boundaries is an issue, I am OK in removing both `childNodes` and `children` or other (`firstChild` and friends) abilities and always return `null` when nodes are live but then again, what is this concern about and where is the code that needs to check that `parent.childNodes[0].parentNode === parent` out there?

This "*concern*" seems irrelevant for both expectations and the **feature** that *GroupNode* is proposing ... a *Rage* can have multiple nodes selected and these won't reveal the *Range* in any way ... once *extracted* these reveal a different `parentNode` which is the *fragment* so why nodes in a range are accepted to *not be aware* of the fact these are part of a range but with *GroupNode* we flag this behavior as *concern*? Or maybe it's me not understanding what is the concern in here or why such concern is problematic ... but then again, I am not expecting direct `children` or `childNodes` manipulation to be super useful when nodes are live, as long as `appendChild` and all other mutation methods work as desired in the proposal (confined within boundaries) and if that's the only blocker it takes *code removal* to fix that and I'd be fine with it as long as I understand what is the concern, what such concern means in the real-world and/or why that is a concern at all for a new primitive which goal is to be fully transparent and represent a range of `childNodes` or `children`, thanks.

> NodeGroup maintains live references to its children

Not at all, it only knows its boundaries and it's through its boundaries that can reach whatever is in between. There is no direct relation between the *GroupNode* and its content unless it's been created or removed from the DOM so that its content is exactly the same of a *#fragment* and everything works exactly the same.

A *GorupNode* doesn't own its children and doesn't need a relation when these are live.


> A container can't "see" a NodeGroup inside it, but I think that's intentional?

That's exactly like a *#fragment* ... you append it, nobody can see it live. The creator of the *GroupNode* owns that reference, just like private shadowRoot with closed `attachedShadow` **unless** the group is named and reachable via `document.groups` and yet, it won't be reachable through the DOM, it requires an explicit will to reveal the group node same as it would require an explicit will to orchestrate some *#fragment* that uses, instead, a direct relation with its nodes and offer the ability to remove or move all of them at once (basically a home-made *GroupNode*).

> doesn't work since a child can't necessarily "see" that it's in a NodeGroup since its parentNode may or may not be the NodeGroup. 

Exactly like it is already for *#fragments* ... a node doesn't know it's part of a *GroupNode* same way it doesn't know it's part of a *Range* or that it was part of a *#fragment* and it has never been an issue so far.

> when a node is assigned to a <slot>, it gets an assignedSlot property that references the slot.

I don't have a strong opinion about this topic but the original idea was to not leak the *GroupNode* if not wanted to + I don't see any value in giving each group node child the "*power*" to manipulate all its sibling but if this is an issue I don't mind adding extra code to reflect that, it's just to me not needed, slower and a bit bloated + it leaks the *GroupNode* ownership if that property can be reached by everyone, defeating the guard around anonymous VS hydration/public/exposed groups.

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

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