- From: Joe Pea <notifications@github.com>
- Date: Fri, 18 Sep 2026 16:58:46 -0700
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/dom/issues/1406/5737612359@github.com>
trusktr left a comment (whatwg/dom#1406) I strongly agree with Justin here. The thing is, it isn't the consumer of the APIs that should care about how elements/nodes handle their own state when moved. Consumers of this API (or any API that lets them move a child) just want to move the element/node. It is the responsibility of the moved element/node itself to determine what to do, exactly like how custom elements with and without `connectedMoveCallback`: custom elements don't have this issue because they always move, but they choose how to handle it. On the other hand, native nodes throwing an error saying "I cannot be moved" is _totally nonsensical_ to the consumer. This is an unnecessary leak of internal implementation detail. Consumer (even a framework's) thought process: "I'm gonna move this node" -> error -> "WTF?" -> tries other method -> it works -> "WTF?" (Where F stands for fudge cakes, of course 😊) It simply does not make great no sense for this oddball to throw like it does, and the j version is notable: it isn't the element/node consumer that decides if an element is movable; it is the element (or node) that decides what to do (with its own state) when moved. (Parent elements that care about childList changing observe children, which is not relevant to this.) -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/dom/issues/1406#issuecomment-5737612359 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/dom/issues/1406/5737612359@github.com>
Received on Friday, 18 September 2026 23:58:50 UTC