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

robbiespeed left a comment (whatwg/dom#736)

> I don't have any other way to be unobtrusive, allow the content of the NodeGroup to be placed everywhere and survive [Node.normalize](https://developer.mozilla.org/en-US/docs/Web/API/Node/normalize) calls.

Surviving `normalize` seems like an arbitrary constraint considering there are other ways for a group to become broken (`removing` or `moving` one of the markers). And what I'm suggesting wouldn't restrict anyone from using comments as the boundaries.

> boundaries are never child nodes of the group itself, because if somebody is worried that parent.children[0].parentNode == parent might be surprising, group.appendChild(node) !== group.lastChild would be a whole new level of surprise.

That's not really what I'm suggesting. There's 2 options: the start and end nodes would be static and not show in children (like the comment nodes don't), or preferably children is inclusive of start and end which are dynamically updated when a node is inserted at the start or end of the group. The second option also allows for start to equal end so "empty" groups can be represented by a single comment or text node.

> You cannot get always away using elements, which is the whole point of GroupNode. There is no element that can be between a parent <ul> and an <li> that has a meaning and won't break that layout, same goes for list of <meta> or list of <tr> or list of <td> or just components with a list of mixed text, elements, and other components in it ... so element surrounding the group is not a solution to the problem GroupNode solves.

In many cases for serialisation you can use the elements that are present to declare the boundaries, in the cases you can't (ex: text nodes at start or end, empty group) you can fallback to using comment nodes.

And I do think a way of naming comment nodes for quick lookup after parsing like `id` would be valuable, not just for this proposal, so ideally that could be it's own separate thing used in parallel with a non restrictive group node when needed.

Ex:
```html
<div></div>
<!--[name=g1-start]-->
Text
<span></span>
<span id="g1-end"></span>
<script>
  const group = document.createNodeGroup(
    document.getCommentByName("g1-start"), 
    document.getElementById("g1-end") // optional, if not provided the group will start and end at the first node.
  );
</script>
```

One thing I might change about this is instead of using comment node syntax for these new identifiable markers, use ProcessingInstruction `<? ?>` syntax.

> Agreed that anonymous groups should not reveal their boundaries once serialized, but that should be through the special boundary comment because boundaries are not related to the group node they represent or it would be a cyclic dependency which I have happily avoided on my prototype: the group knows its boundaries and works through these, everything else has no notion of the group and that was a design goal of my proposal.

I am not saying boundaries shouldn't be revealed. There would be no need for cyclical dependencies with what I'm proposing either, nor would anything else but the group need to know about the group.

What I'm proposing wouldn't limit anyone from exclusively using comments (or a new special identifiable comment) as boundaries if they wish.

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

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