> > 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
Just to be super clear, we're not at all considering cross-document moves; our proposal is scoped to same-document only. Now, so I understand where you're coming from, you're saying that (1) above is about whether the side effects of (a) attempting a cross-document move (always an error) should or should not match the side effects of (b) moving a node that cannot be moved in a state-preserving way? I don't think whether these two "failure" cases have matching side effects is all that important, I just think that the side effects should make sense/be logical for each case. 2) whether the methods that reparent lists of elements can reasonably > remove+insert some while atomically-moving others. I honestly don't know if this is the most interesting part about changing the behavior of all DOM mutation APIs. Exactly what `append()` should do if some of its nodes can be atomically moved while others must be fully inserted is interesting, but I think the way more interesting question is should `append()` *ever* try and atomically move *even just a single element* that can be atomically moved? First, there is the web compatibility concern. But second, and more interesting to me, is predictability. It feels strange if sometimes `append()` has big side effects (script execution—which may attempt nested `append()` calls, iframes initializing, styles being applied, etc.), and other times no side effects at all. If you want to know whether `append()` will have side effects, then you have to find the spec'd conditions under which an *atomic* move will be performed and check these before `append()`. It's this predictability concern that I think motivated TPAC folks to lean towards `moveBefore()` throwing an error when an atomic move could not be performed. The downside of course is that if you call `moveBefore()` from a generic place like a framework, and *always* want the node to just move from A->B (just atomically when possible), then you have to call `moveBefore()` in a try-catch and always call `insertBefore()` from the catch block. If 99% of `moveBefore()` uses are like that, then it becomes cumbersome. Anyways, I suppose we'll debate this exact thing over in the spec PR <https://github.com/whatwg/dom/pull/1307>. On Thu, Nov 21, 2024 at 3:22 PM Jeffrey Yasskin <jyass...@chromium.org> wrote: > 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/CAP-uykAHXQA-o3K8Bf7_XQt6tirOukpDH0MntV5rZO8Mr_FJRg%40mail.gmail.com.