On Wed, Nov 20, 2024 at 12:55 PM Dominic Farolino <d...@chromium.org> wrote:
> What's preventing the PR from landing? > > > Just the fact that it hasn't been fully reviewed yet. We've received > initial comments, but are waiting for a full round and LGTMs, and are > confident they'll come soon. > > There was a lengthy discussion about this at WHATWG before and as a result >> of the TAG feedback. The conclusion is that it's not feasible to change the >> behavior of all the existing methods, and changing the behavior of only >> some of them would be inconsistent and confusing. > > > To add to Noam's comments, a big deciding factor for the current direction > was philosophical, and unrelated to web compatibility. Current editors > (Anne and Domenic weighed in heavily during the TPAC 2024 discussion) felt > strongly that the concept of "move" was conceptually a very distinct > primitive from the existing "insert" and "remove" primitives. Therefore, > usages of the existing primitives—through existing APIs—shouldn't suddenly > mix the move behavior in with the current behavior, even if it were web > compatible. The processing model of move compared to insert+removal is > different enough that blending them is not what editors would have done > even if "move" were conceived of from the beginning—this is the main > feedback we got. > Thanks for the pointer; I found https://github.com/whatwg/meta/issues/326#issuecomment-2377500295 recording that discussion. It looks like Anne's argument that we can't change the MutationRecords for the existing functions, is obsolete since https://github.com/whatwg/dom/pull/1307#issuecomment-2327504259 concluded we should use the existing remove+insert MutationRecords even for atomic moves. And I intuitively agree with the argument that it's useful to have an operation (moveBefore) that guarantees it won't reset an element (it either moves atomically or throws and leaves the element in its original place), but a couple web developers just disagreed in https://github.com/whatwg/dom/pull/1307#issuecomment-2491906616. The remaining arguments seem to be about 1) whether it makes sense for the movement APIs to have noticeably different side-effects when moving a node across documents and 2) whether the methods that reparent lists of elements can reasonably remove+insert some while atomically-moving others. My sense is that Lea Verou is right that it's better for authors if the existing APIs atomically-move the subset of their arguments that can be moved atomically, even if some of the arguments have to be removed+inserted. That said, the current behavior is to remove all the elements and then insert all of them, and I don't know how observable it would be to remove just the ones that can't be moved atomically, and then insert or move the list of elements into place. All that said, the WHATWG forum has all the relevant experts, and if y'all think this is the right design after considering the arguments, I think you should go ahead. Jeffrey On Wed, Nov 20, 2024 at 3:29 PM Noam Rosenthal <nrosent...@chromium.org> > wrote: > >> >> >> On Wed, Nov 20, 2024 at 4:57 PM Jeffrey Yasskin <jyass...@chromium.org> >> wrote: >> >>> The TAG feedback >>> <https://github.com/w3ctag/design-reviews/issues/976#issuecomment-2359457221> >>> was a request to see if we could make this change to the other methods by >>> default, instead of adding a parallel set. If that's web-compatible, we >>> might not have to think about the larger package. >>> >> >> TAG deferred back to WHATWG with the feedback. >> There was a lengthy discussion about this at WHATWG before and as a >> result of the TAG feedback. The conclusion is that it's not feasible to >> change the behavior of all the existing methods, and changing the behavior >> of only some of them would be inconsistent and confusing. >> There are only a couple of DOM methods that this applies to anyway >> (appendChild, replaceChild). The other ones (e.g. append(), before()) work >> on a series of elements so some of the assumptions that allow us to do this >> don't work there in the same way. >> It's worth mentioning that the current direction was also a strong view >> from Gecko & WebKit folks. >> >> >>> On Wed, Nov 20, 2024 at 8:32 AM Alex Russell <slightly...@chromium.org> >>> wrote: >>> >>>> This is very exciting, and I'm eager for this capability to ship, but >>>> I'm also worried that we're only doing one of the many append/insert API >>>> variants here. Is this the start of a larger package of additions? Or the >>>> only planned version? >>>> >>> >> All the other insertion methods can be polyfilled on top of insertBefore, >> so at least at first there could be a very small userland library that does >> this as "sugar". >> We can envision adding a move* variant to other methods in the future if >> there is demand, there is nothing preventing us from doing this. >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dX%3Dbfq_kCR3RHaqiFq6EDDypVWVxT8x3wZqONzxt9rG51A%40mail.gmail.com.
