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

DeepDoge left a comment (whatwg/dom#736)

@robbiespeed
What you did with `[src]` can already be done using custom elements, which also allow for more flexible logic around how the content gets filled. The issue is, that it wouldn't be transparent. You might try applying `:host { display: contents }` via an adopted `CSSStyleSheet`, but as @WebReflection pointed out, that comes with its own trade-offs.

That’s why having `<fragment>` as a standalone, purpose-built element makes more sense—similar to how elements like `<canvas>`, `<iframe>`, `<video>`, or `<img>` exist for specific use cases. You could still build on top of it using custom elements to add your own logic—**if** it were an `HTMLElement`. But since you mentioned it wouldn't be an `HTMLElement`, but rather another `Element` type, it couldn’t be used as a custom element.

However, if the custom attributes proposal lands, that might let us bind behavior to elements regardless of whether they're `HTMLElement` or not—assuming they work on any `Element` type.

Now, why does lifecycle even matter in this context? One common reason people want a persistent fragment is to update or move nodes around as a group. If updates are involved, you'll probably need to react to some kind of signal/event—and that means you need clean up that listener when the fragment is removed from the DOM. That’s why lifecycle callbacks like `connectedCallback` and `disconnectedCallback` are crucial. If the fragment never needed to change, a one-time `DocumentFragment` or even an array of `ChildNode` references would have been enough.

Custom elements (and maybe custom attributes in the future) already provide a standardized way to handle lifecycles, so introducing a completely new system just for new fragment/group `Node` type might be redundant. Or maybe it's just fine.

To be clear, I’m not attached to a specific solution—I just want us to *get* something. My concern is that whatever we end up with might not be flexible or lifecycle-aware enough, and that would make it barely better than managing a raw array of nodes—still fragile when DOM changes since it would relay on frameworks' hacky abstract ways of handling lifecycles. 

As for concerns about breaking existing tree walkers: I don’t find that argument very compelling. If a developer *chooses* to use a new element or node type, it's on them to handle it properly.

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

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