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

WebReflection left a comment (whatwg/dom#736)

> 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).

one is an explicit *node* reach and breakage, the other one is just a good old API any container can use and demolish any component that trusts text nodes as boundaries ... so it's arbitrary to chose text nodes to me, when comments are absolutely innocent in a tree and no side effect prone due legacy (as in very old, pretty known) APIs, imho.

>  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

I prefer not having irrelevant nodes for the content within the fragment because that also breaks every assumption around `append`, `appendChild`, `insertBefore` or `moveBefore` with a `null` or `undefined` pin ... this means that the whole fragment API is misleading so we can agree to disagree but I never want boundaries in the group or I can't even trust `replaceChildren(...)` in there ... so, if those boundaries have to be so special that all APIs that work already needs special treatment, how about we keep those boundaries *outside* the fragment content?

> `<!--[name=g1-start]-->`

I don't have any preference for the special content of group nodes boundaries but having a comment as start and a span as end feels like wrong ... you have two comments and the span is the node ... the *hydration* story though is based on open/close boundaries and `document.groups`, you don't create groups from the DOM or at least that's not necessarily sealed in my prototype but what is expected is that boundaries are special node of the same kind which is, imho, a reasonable constrain, as long as these are outside the fragment content.

So it's `<!--g1-->` and `<!--/g1-->` right now and because the name is like an ID you get that boundary via `document.groups['g1']`.

Alternatively I would advocate for a *Range* ability to create groups from selected nodes and add boundaries automatically, in case the group wants to be created from live content, inserting boundaries before the range starts and after the range ends without disrupting the layout (hence comments as boundaries).

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

I don't have strong opinion about the specific kind of boundary as long as it never disrupts the tree. If processing instructions are anyhow better I'd be OK. I won't be OK with empty text nodes or random nodes used as boundaries though, for the reasons I've mentioned ... but hey, that's also just my opinion, I am just trying to epxlain why the proto is the way it is.

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

great, but imho it's gonna be just one kind of boundary or tools are doomed, parsing/crawling is doomed, `document.groups` won't work or it will be checking too much for very little gain and so on.

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

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