>
> 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.

Reply via email to