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

FrameMuse left a comment (whatwg/dom#736)

@WebReflection 

> Still, while comments work around all these, I can see the effort to make this <group> idea nearly as high as the persistent fragment one and, if it cannot solve use cases comments solve already, I can see low adoption and still the need for the specific framework to deal with those nodes.

> Thanks for pointing that out though, it's OK to have "something" instead, but if that something ends up requiring a lot of work without solving the reason people are using open/close or close only comments, bound to the nodes these represents, that effort would should be rather spent elsewhere, imho.

As someone who supported `<group>` (or `<#>`, `NodeGroup`) idea - I haven't implied that ul/li or table/tr/td should be handled differently. IMO, the exact purpose of having `NodeGroup` is an ultimate folder, meaning it serves any nodes the same way with no checks about what and in what order/nesting nodes are appearing.

> Which is useful for rearranging, moving, adding, deleting nodes without caring about where they are currently placed altogether.

And thus, things like tr/th/td must be grouped as well.

---

I just realized the deeper problem of grouping as elements like `<table>` require having exact specific children, e.g. you can't place anything but strictly specified nodes, whereas any kind of connectable **AND** persistent nodes listing seems to be difficult to optimize since DOM would need to solve all those incompatibilities EACH TIME.

`DocumentFragment` does allows free element placing, but once inserted, it's wiped and those incompatibilities are solved in place, which is ok. While for ANY kind of persistent grouping (including `PersistentFragment`), it stands as fundamental problem as it can be changed at any time **without wiping** AND the children of that list **must** persist in the same way - they must not be resolved in the list but in the place instead. That's where we're coming to the optimization problem, which is resolving those incompatibilities every time any change in the persistent list appears.

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

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