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

WebReflection left a comment (whatwg/dom#736)

@robbiespeed 

> the requirement of comment nodes as boundary markers

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.

Comments felt like the most natural way to do that and I also don't buy *comments* are slow ... of course if you have thousand comments you have thousand mode nodes but *GroupNode* is a specific use case, it's not that suddenly everyone will use it to represent custom Elements or whatnot. That being said, I'd love to have special comments that can be used as boundaries, won't show up on serialization *unless* the group is named or explicitly asks for it (inevitable for *hydration*) and helps devtools highlighting *NodeGroup* boundaries.

Right now, the polyfill had to use available primitives, and empty text nodes are not an option due `normalize()` operations that might happen in the wild.

> However if the group has static nodes (text or element) at the start and end I use those as the markers.

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.

Boundaries are the contract and the mechanism to make *GroupNode* possible so that an empty group is possible and a `replaceChildren(...nodes)` will just place stuff in it, if offline, or between boundaries once live.

Boundaries are the primitive that signal if the *group* is appended somewhere else or not ... so these are the special new thing people might have difficulty to understand but it's all designed to work seamlessly with everything else already, including the `group` fragment itself.

> for serialisation comment nodes are not as ideal if you can get away with using elements

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.

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.

- - -

### About DOM Parts

I've finally took some time to read [this proposal](https://github.com/WICG/webcomponents/blob/gh-pages/proposals/DOM-Parts.md#motivation) and while I'd love to be able to pass to a `template` element some template string tag reference like `tpl.join('{}')` and retrieve after the ordered parts as `content` or `attribute`, I've also read a lot of effort around a topic no mentioned framework cares about: partial attributes.

JSX throws right away with `<a href="mailto:{email}" />`, only `<a href={value} />` is accepted, and AFAIK every example and documentation for Angular and Svelte do the same ... and so do every of my template literal strings based libraries.

It would be very sad if that proposal has been on hold for something apparently only *lit* cares about, something that forces that proposal to be more convoluted and attributes to be *computed* instead of direct values, causing performance and logic issues if *signals* are used in the process, all topics already solved and used daily in P/React, SolidJS, Svelte and every other single modern framework out there.

But beside this attributes part, which is entirely unterlated to this *NodeGroup* proposal, the *child* part doesn't seem to solve the presented use case: the desire to be able to create a "*component*" that has more than a single node in it and does not want or need a container + the ability to place into those parts group of nodes as opposite of dealing with arrays and whatnot, all things that play badly with all the diffing libraries out there, and I wrote at least 5 of those ... they all end up working best with a specialized "*wire*" which is a *DocumentFragment* extend and mimics *GroupNode* but in a home-made way, as opposite of being naturally implemented by the *DOM* engine.

Accordingly, I am not sure I am understanding these concerns:

  * how can *NodeGroup* interfere, as opposite of enhancing further, with DOM Parts?
  * why *attributes* are required at all in *NodeGroup*, when it want to act exactly like a *#fragment*?
  * how can DOM Parts reproduce this [basic use case demoed in code pen](https://codepen.io/WebReflection/pen/emmYZON?editors=0110)?
  * how can DOM Parts have internally other DOM Parts with the same ease a *NodeGroup* can be inside another *NodeGroup*, as these are just regular nodes and work just like regular nodes all over the DOM specification?

I am OK and happy to learn about concerns but I'd like to see concrete examples of why these concerns need to be raised and so far, for what I could read about DOM Parts, I don't see any way to have *NodeGroup* in there + I see a lot of discussions for attributes which are entirely a different topic so that by no mean this proposal could interfere in there.

If parts will introduce a new special *Token* as *comment node* though, I think that special token could be used for *NodeGroup* boundaries too and have multiple purposes which is, usually, a good thing, right?

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

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