LGTM3 to ship once the spec PR has landed.
Also, I'm really happy to see this new API coming to the web platform!
Thanks to all that has made it happen!
/Daniel
On 2024-11-27 17:35, Rick Byers wrote:
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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_UkYEU1FdZ%3D8BArZ7eiT3ZjSE%3D1%3Dne50t6HaYdkEyNYg%40mail.gmail.com?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/66473ae5-d608-40f4-959c-b95969dac1ec%40gmail.com.
