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

So, I've uploaded the previously mentioned polyfill, which should have 100% code coverage.
https://github.com/WebReflection/document-persistent-fragment

There is a [live test page](https://webreflection.github.io/document-persistent-fragment/) too.

- - -

@rniwa while the test page works great in both Chrome and Firefox, there's a super weird behavior in Safari where `new DocumentPersistentFragment instanceof DocumentPersistentFragment` returns false, even within the same constructor, and after calling super. Not sure what kind of indirect bug I've found, which is why I haven't filed one (yet).

- - -

### the what

The idea is to have a 1:1 DocumentFragment alter-ego that doesn't loose its nodes.

The fragment is exposed only to the owner, so that there is no way to retrieve it from third parts, unless passed around, and there's nothing live on the DOM, if not, eventually its child nodes.

The proposal exposes to the owner common nodes methods based on its content.

As example, `dpf.previousSibling` would return the `dpf.firstChild.previousSibling` if there is a `firstChild`. If the `dpf.isConnected` is `false`, the result is `null`.

The _DPF_ (in short) has only one extra method, compared to DocumentFragment, which is `dpf.remove()`. Such method doesn't need much explanation: it removes all nodes from the DOM.

All operations performed through the _DPF_ are reflected live on the document, and while this might be just a stretch goal, it is super easy and nice to simply update an owned reference and see everything changing live.

### Nodes ownership

It is possible to grab random nodes and destroy these, or change these, affecting indirectly the content owned by the _DPF_ instance, but it's always been possible to be obtrusive on the DOM and destroy third parts libraries so I think thous shouldn't be  concern.

However, I could implement the `WeakMap` that relate each node to a specific _DPF_ instance in a way that it's not possible to move a node owned by a _DPF_ into another _DPF_, or even perform any action on the DOM through elements that are not the _DPF_ owner.

This, however, would introduce an ownership concept that is too different from what we've used so far, but I believe this proposal is for all libraries that need such persistent fragment, and that owns their own nodes, libraries that are currently somehow already breaking things of 3rd parts obtrusive libraries destroy, or manipulate, DOM nodes in the wild.

### As summary

The fact, beside some Safari glitch I'm sure I can solve, this whole proposal can be already polyfilled, and the fact browsers have a way to optimize it and make it blazing fast, should be considered as a plus, 'cause instantly adoptable by the community, so that we can have quick feedbacks of how much this is welcomed or needed out there.

Please don't hesitate to file issues there or ask me more here before discarding this proposal.

Thank You.





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