- From: Andrea Giammarchi <notifications@github.com>
- Date: Wed, 16 Apr 2025 02:51:21 -0700
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/dom/issues/736/2809033276@github.com>
WebReflection left a comment (whatwg/dom#736) > Now maybe this is ok because DocumentFragment is already kind of weird by emptying its children into a container it's appended into, and never having a parent itself, but it definitely breaks some assumptions you could previously make about nodes. nodes moved around via fragments have the same assumptions and this is not a substitute of a fragment, it's a different primitive and when you use it you can't make assumptions on parent node the same way you can't make assumption for elements moved through fragments. On top of that, the element `parentNode` is always correct, either the GroupNode or its current parent, and the fact the fragment is live or not is also reflected through `GroupNode.parentNode` which is either `null` or the current parent and this is not a surprise, it's how the GroupNode works. Taking about surprises for new APIs feels a bit weird ... *my surprise* with `moveBefore` was to break where `insertBefore` wouldn't so that stating that surprises are a no-go, based on the status-quo, doesn't seem to be a concern in general and I am feeling a bit of a push-back at all costs for something really that simple to both implement and, *imho*, reason about. So [here a CodePen](https://codepen.io/WebReflection/pen/emmYZON?editors=0110) scenario I believe is not possible with DOM Parts and not possible with the range idea, at least not with the same ease/simplicity and that's all GroupNode would like to offer: an extremely simple way to have DOM components that represent more than a single node, something CustomElements can't offer, something only ShadowRoot or template can but that content every single time gets lost once appended somewhere else. There is no broken expectation if you stop thinking "*it's a new thing*" and think instead "*it's a fragment*", with the **feature** that once that fragment gets appended its boundaries, or whatever better mechanism we could come up with, helps the *fragment* operate through nodes within such boundaries. I even created [an ASCII explainer](https://github.com/WebReflection/group-nodes?tab=readme-ov-file#implenentation-details) and so far it's really not more complicated than that and, once again, nothing new ... if it was something new I couldn't have implemented that polyfill so please let's keep thinking "*it's just a fragment*" + like @FrameMuse mentioned already in various occasions, nobody is confused about this behavior or feature in Figma so it's unclear to me why we don't want a primitive that is well known and used to design for something Web related, hence aimed at better designing Web apps and services. -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/dom/issues/736#issuecomment-2809033276 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/dom/issues/736/2809033276@github.com>
Received on Wednesday, 16 April 2025 09:51:25 UTC