On Thu, Nov 21, 2024 at 1:26 PM Dominic Farolino <d...@chromium.org> wrote:
> 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. > Sorry for being unclear here. I was thinking of the question you elaborated on below, whether `append(elem)` should behave significantly differently (for certain kinds of input elements) depending on whether `elem` can be moved atomically. I agree that the details of the various failure cases for `moveBefore(elem)` don't need to be exactly consistent. 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. > Doesn't `append(elem)` already sometimes have big side-effects (when `elem` is a <script> or <iframe>) and other times have no side-effects (when `elem` is a <b>)? It doesn't seem like reducing the number of side-effects is going to introduce a consistency problem here. I think the more important question is whether authors ever _want_ those side-effects. If they do, it's going to be web-incompatible to change the existing methods. If authors never want the side-effects, we should remove them whenever we can. (This isn't an argument that moveBefore() should fall back to remove+insert. If the existing methods opportunistically use atomic-move, we can still have a new method that guarantees a lack of side-effects. And this consideration probably cuts the dependency between this I2S and a decision on whether to modify the existing methods.) Jeffrey 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/CANh-dX%3DW9WRXZLi-BMhKQ_-KgVKYG8e_D_ehNY4GW79RLR-i9Q%40mail.gmail.com.
