02:00
<Domenic>
I would be more OK with having variable behavior if the name reflected that, like insertOrMoveBefore. I think making moveBefore sometimes insert, sometimes move, is bad.
02:44
<njbjm>
@shannonbooth:matrix.org 
08:21
<Noam Rosenthal>
I would be more OK with having variable behavior if the name reflected that, like insertOrMoveBefore. I think making moveBefore sometimes insert, sometimes move, is bad.
Perhaps that's a way forward. That way if in the future we wanted to add some different behavior like moving iframes across documents and wanted moveBefore throwing to be a feature detecting mechanism, we could incorporate that into moveBefore and leave insertOrMoveBefore as something that just works
10:21
<Domenic>

Thoughts about this route:

  • We should probably still have the primitive (that throws). I remain skeptical that people really will only use this in generic situations. I suspect some people will require the move behavior and it will be a logic error in their app if they get insert behavior.

  • The name should actually be moveOrInsertBefore ("move" first) since it's move and falls back to insert.

10:22
<Domenic>
Alternate API surface (maybe already considered?): update all the methods to have a { moveBehavior: "insert"|"move"|"move-if-possible" } argument. (I don't love that name.) The default, unlike TAG suggestion, is "insert".
11:07
<Noam Rosenthal>
Alternate API surface (maybe already considered?): update all the methods to have a { moveBehavior: "insert"|"move"|"move-if-possible" } argument. (I don't love that name.) The default, unlike TAG suggestion, is "insert".
I think the only methods that can benefit from this are replaceChild and appendChild
11:08
<Noam Rosenthal>

Thoughts about this route:

  • We should probably still have the primitive (that throws). I remain skeptical that people really will only use this in generic situations. I suspect some people will require the move behavior and it will be a logic error in their app if they get insert behavior.

  • The name should actually be moveOrInsertBefore ("move" first) since it's move and falls back to insert.

I support this approach. If most of Userland code is going to do this anyway we might as well have it from the get go. It’s ok to also have the raw function.
21:24
<sideshowbarker>
annevk: Did you see https://matrix.to/#/!AGetWbsMpFPdSgUrbs:matrix.org/$_HiM0poiNHUMxlJHZqWrv0yGL3A72AnWOI3Ntt0JOS8 last week? https://matrixlogs.bakkot.com/WHATWG/2024-11-19#L7
21:52
<sideshowbarker>
FYI for all: https://github.com/beuss-git/wpt-results-analyzer