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

robbiespeed left a comment (whatwg/dom#736)

> Then what are we adding as new API? It seems like don't need any.

For hydrating server rendered html I agree we don't need a new API. A persistent fragment has very little do with hydration and more to do with reducing the complexity of managing groups of DOM nodes.

> Well, at that point, what is being proposed to be added to the platform? It doesn't sound like anything needs to be added at all since you can just implement all that in user land.

You can but it requires monkey patching Node and Element prototypes, and in doing so reduces overall performance of most DOM operations. Which means rendering libraries are better off using a split code path for handling fragments and nodes. If it were added to the platform then the polyfill would be an acceptable stop gap for browsers that haven't added support.

> DOM nodes are implemented as a C++ object in most browser engines. They have a single pointer back to its parent node. Having a single node having two different parent nodes (NodeGroup and its regular parent) is a very novel concept. Since browser engine internals are written with the assumption that each node belongs to at most one location in DOM, changing that semantics would require quite a bit of refactoring / rewrite. I'm not at all convinced that anything proposed in this issue is anywhere near good enough to justify that kind of undertaking.

I wasn't suggesting that Nodes should have 2 parents, that's precisely why I clarified that parentNode should be null when the nodes in the group are not attached to a parent node in a DOM tree. NodeGroup is never a parent it's more like a Range, and nodes should be able to be part of many groups just like they can be with ranges. But Range isn't a suitable replacements for NodeGroup because it has a different interface than Node and maintains it's contents relative to the parent element, a NodeGroup in contrast would be relative to the start and end Nodes, so when they move the NodeGroup in a sense moves with them.

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

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