LGTM2 once the PR lands On Wed, Nov 27, 2024 at 11:16 AM Alex Russell <slightly...@chromium.org> wrote:
> Thanks for all of this. > > Would be good if we had a doc that explored the potential extension paths > for the existing APIs (arguments object as additional param?) vs. the > "larger bundle" path. I'm happy for this specific API to ship assuming we > have those options written up for the TAG (and API OWNERS) to consider. > > LGTM1 on the condition we produce that writeup. > > Best, > > Alex > > On Thursday, November 21, 2024 at 2:41:06 PM UTC-8 Noam Rosenthal wrote: > >> On Thu, Nov 21, 2024 at 9:43 PM Jeffrey Yasskin <jyass...@chromium.org> >> wrote: >> >>> 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. >>> >> >> To add to this, we did try to prototype "changing the default behavior". >> >> Adding move behavior to `append` or to any of the methods that take more >> than one element is a pandora's box, because currently all the removals >> occur before the insertions. >> So splitting a moved element to an insertion and a removal, where the >> insertion is mixed with other insertions and the removal is mixed with >> other removals is a totally different model from what we went with, and is >> likely not doable. >> In practice, this only leaves us with appendChild and replaceChild where >> we can probably have some plausible behavior, but probably a >> bigger backwards compatibility problem because they're older. >> Having append() behave differently from appendChild() or having append() >> with more than one argument behave differently from append() with one >> argument is arguably very confusing, but we can consider doing this in the >> future. >> >> In the meantime, moveBefore is a low level primitive - it only moves. It >> doesn't fall back - it fails if it doesn't do the one thing it's supposed >> to do. It's the first and lowest level version of atomic move - and it's >> plausible we can add more ergonomic higher level variants in the future. >> >> >> -- > 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/c31ab674-d794-4146-8ab2-fcaadb0536d7n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c31ab674-d794-4146-8ab2-fcaadb0536d7n%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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/CAFUtAY_UkYEU1FdZ%3D8BArZ7eiT3ZjSE%3D1%3Dne50t6HaYdkEyNYg%40mail.gmail.com.
