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.
