| 05:45 | <Domenic> | annevk: https://github.com/whatwg/html/pull/10770 is marked as WebKit supportive "based on comments on this PR", but it seems possible you were only wearing your editor hat; would you mind explicitly giving a thumbs-up here or there on behalf of WebKit? |
| 08:38 | <annevk> | Noam Rosenthal: Dominic Farolino: the thing I wanted to say during the call yesterday is that the bits that are shared between insert and move, and between remove and move, should be abstracted so we only have to maintain those algorithms in a single place as they are quite involved (especially the range mutations). |
| 08:40 | <annevk> | I guess there's now also some web developer feedback where they prefer moveBefore() to fallback to insertBefore() where it currently throws. I'm not enthusiastic about that idea as it prevents us from making move possible for more scenarios in the future and it also just seems to encapsulate too much magic. I'd be curious to hear what smaug and Domenic think about that idea, but I'd be inclined to say no. |
| 08:46 | <Domenic> | I agree, I feel like we settled that during TPAC. It's such a fragile design. |
| 08:54 | <annevk> | I'll double check with ntim on the popover PR btw. (I suspect it's fine.) |
| 10:15 | <Noam Rosenthal> | I guess there's now also some web developer feedback where they prefer moveBefore inside try/catch? Because that can't be guaranteed, people might make the isConnected checks etc. themselves. |
| 10:16 | <Noam Rosenthal> | Can you expand on "prevents us from making move possible for more scenarios in the future"? Is that relying on people putting |
| 10:19 | <smaug> | I'm not keen on falling back to insertBefore. |
| 11:34 | <annevk> | Noam Rosenthal: It doesn't rely on that. Though potentially it does somewhat rely on people not automatically falling back to insertBefore() and then relying on insertion and removal steps to run. I'm just saying that in the future perhaps we want to take on moves between connected documents and possibly also between connected and disconnected states. And it would be annoying to have to add new API at that point. |
| 14:29 | <Dominic Farolino> | I think I might be the only one here that would be OK with falling back to insertBefore(). The argument I find convincing is that if 99% of users of this API are going to be in some generic framework-like context, all they care about is literally getting the node from A -> B, and they see moveBefore() as a way to opportunistically do that atomically when possible. But either way they still want the node to end up "over there" somehow. |
| 14:29 | <Dominic Farolino> | I have to imagine the # of users that would actually jump ship and not do anything when moveBefore() currently throws is really small. I haven't heard developers say that's how they would use the API. |
| 14:29 | <Dominic Farolino> | That said, I am fine with the current design. I just think I'm more sympathetic to what I'm hearing from devs right now. |
| 14:32 | <Dominic Farolino> | Like, I understand the value of introducing a low-level single-purpose primitive. But if developers are definitely going to hold it like the higher-level DOM mutation APIs, maybe making this a low-level single-purpose API is trying to force a market fit that isn't there? |
| 14:33 | <Dominic Farolino> | Noam Rosenthal: Dominic Farolino: the thing I wanted to say during the call yesterday is that the bits that are shared between insert and move, and between remove and move, should be abstracted so we only have to maintain those algorithms in a single place as they are quite involved (especially the range mutations). |
| 14:50 | <Noam Rosenthal> | I think I might be the only one here that would be OK with falling back to insertBefore(). The argument I find convincing is that if 99% of users of this API are going to be in some generic framework-like context, all they care about is literally getting the node from A -> B, and they see moveBefore() as a way to opportunistically do that atomically when possible. But either way they still want the node to end up "over there" somehow. insertBefore, ans also with what we've landed with, with a slight preference towards throwing. Though I do see both arguments. |
| 14:55 | <Dominic Farolino> | I just want to protect against us trying to land something that feels academically right, but isn't what fits into most practical consumers hands |
| 14:57 | <Noam Rosenthal> | I do agree that the argument for throwing are a bit handwavy and need to be somewhat more concrete to be convincing. "encapsulating too much magic", "fragile design", and future proofing are indeed in an academic realm |
| 14:57 | <Dominic Farolino> | I'd like to understand the "prevents us from making move possible for more scenarios in the future" argument more too. Maybe some concrete examples of what these future scenarios would be would help me get it. I guess this is just referring to relaxing the conditions in https://whatpr.org/dom/1307.html#concept-node-ensure-pre-move-validity? |
| 14:59 | <Dominic Farolino> | And I guess the argument is the future relaxation wouldn't be compatible if we don't throw now? |
| 15:02 | <annevk> | Did the TPAC discussion not capture this in enough detail? I'm a bit hesitant to elaborate on everything here again as I suspect it won't be the last time and even simple PR feedback was already likely to go missing if I didn't enumerate it elsewhere. |
| 15:07 | <Noam Rosenthal> | The TPAC discussion was mostly about retrofitting the existing function. |
| 15:08 | <Noam Rosenthal> | which is a separate discussion, somewhat less controversial |
| 15:09 | <Noam Rosenthal> | The argument at TPAC for throwing was that move is inherently different from insert, and by providing a low level primitive we create predictability, allowing us to add higher level APIs in the future. |
| 15:10 | <Noam Rosenthal> | Perhaps if the platform introduces insertOrMoveBefore (with a better name) soon enough/later people would be alright with having moveBefore the way it is... that's why I'm still inclined to go with the low level primitive first myself, be it not a strong preference |