Re: [whatwg/dom] Proposal: New method to reorder child nodes (#891)

@annevk Is this summary of the “story so far” here accurate:

1. #5484 concerns the problem of preserving “connection-associated state” of iframes across DOM mutation operations that currently would always entail disconnection and reconnection including reordering _and_ reparenting. It does not concern preserving a browsing context _while_ disconnected, though; i.e. the request is for a synchronous operation where no intermediate “unparented” state exists.
2. #5484’s discussion expanded to look at the problem of “moving connected elements” more generically as there are other kinds of “connection-associated state” beyond just the browsing contexts associated with iframes while connected. A generic solution would be ideal but specifying it implies a kind of hygienic but daunting yak shaving context.
3. @josepharhar created #891 (this issue) to isolate the specific case of reordering connected siblings. This scenario is interesting because it has high value to existing code bases (due to it being relevant to pretty much all “DOM rendering” liberaries) regardless of whether the more general problem is solved and _seemingly_ is simpler to solve than the more generic problem.
4. Part of what makes it _seem_ simpler is that it is already not possible to synchronously observe when/whether a given element’s “sibling index” or position-relative-to-a-specific-sibling changes except via legacy DOM mutation events. This seems apparent because for any set of siblings, it is already possible to reorder them to any other sequence with >= half of the siblings never needing to be disconnected ... and it never matters “which half,” either ... I think?
5. Even if this scenario _is_ much simpler, it’s still considered to depend on #808. That issue concerns existing web realities where (whether due to underspecification, implementation errors, or whatever else) implementations diverge in terms of the timing (or existence?) of specific insertion and removal effects. Given these divergences, “move” methods that do not imply disconnect→reconnect where the same operation would require disconnected→reconnect today would potentially make existing discrepancies worse (or the method steps might end up be coherent for one agent’s behavior yet incoherent for another).

Naturally I think solving #808 would be great (I have run into those existing discrepancies many times), but I’m a little fuzzy on why it would need to be solved to address #891 given (4) above — though I’m not 100% sure (4) is accurate. Please feel free to correct anything/everything I got wrong here :)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/891#issuecomment-1103799309

You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/891/1103799309@github.com>