WHATWG on 2024-09-25

00:03	<annevk>	Too bad we couldn't get into the custom elements callback for moveBefore(). I kinda feel like it deserves a new callback, but maybe smaug would argue for a flag there too? (I feel the same way about the specification callback.)
00:19	<Noam Rosenthal>	In short: thinking to have `movedCallback` that has a default implementation of calling `{ disconnectedCallback(); connectedCallback() }`
00:48	<Dominic Farolino>	(I feel the same way about the specification callback.) Responded to this on the spec PR thread
11:35	<annevk>	Ah, that doesn't sound unreasonable. I was thinking some more about overloading `append()` just to see if I missed something in rejecting it and I'm not sure that it really works apart from the issues already identified. In particular when you pass multiple arguments to `append()` the complexity is increased pretty rapidly and you would definitely get different mutation records if you attempted to handle that as multiple moves or some such. Which you would not always be able to do and thus you'd need careful bookkeeping as well. Seems way too messy compared with "new primitive, new method".
13:04	<annevk>	My impression with "good first issue" continues to be that we put more time into marking new comments as spam than it would take us to fix the issue. Now of course the whole idea is that we don't fix the issue so someone gets the opportunity to ease into contributing, but still.
13:06	<Noam Rosenthal>	Ah, that doesn't sound unreasonable. I was thinking some more about overloading `append()` just to see if I missed something in rejecting it and I'm not sure that it really works apart from the issues already identified. In particular when you pass multiple arguments to `append()` the complexity is increased pretty rapidly and you would definitely get different mutation records if you attempted to handle that as multiple moves or some such. Which you would not always be able to do and thus you'd need careful bookkeeping as well. Seems way too messy compared with "new primitive, new method". Yea that's what we saw in the prototype, the only way to make this not explode in complexity is if all the items you append are moveable (already connected to this document)
15:26	<annevk>	Noam Rosenthal: discussing a bit with smaug this morning we think that it should prolly be `connectedMoveCallback` to match the existing pattern of only firing for connected/disconnected cases and not say, for a move within a disconnected subtree
15:27	<annevk>	And you'd want oldAncestor (which can be your parent if you are being moved) and newAncestor (which can be your parent if you are being moved) as arguments.
15:28	<annevk>	But the specification-level hook should be more generic and match the existing remove/insert pattern.
15:30	<annevk>	Richard Gibson: thanks for sharing those IPv6 tidbits, that's terrible 😅
15:31	<annevk>	I've no idea how we could generically handle a network deciding on some prefix. Though maybe we have that information when we do DNS resolving? Hmm.
15:32	<Noam Rosenthal>	annevk: I didn't understand "move within a disconnected subtree". You can't call `moveBefore` inside a disconnected subtree
15:34	<smaug>	You move the whole subtree
15:34	<annevk>	Noam Rosenthal: oh, we have an is connected precondition? Fair.
15:34	<Noam Rosenthal>	Noam Rosenthal: discussing a bit with smaug this morning we think that it should prolly be `connectedMoveCallback` to match the existing pattern of only firing for connected/disconnected cases and not say, for a move within a disconnected subtree Do you mean not firing `disconnectedCallback` at all when you're moved? I want to make sure this doesn't break CEs that don't expect being reparented without those callbacks
15:34	<smaug>	and in disconnected case there would be no callbacks at all
15:35	<Noam Rosenthal>	Noam Rosenthal: oh, we have an is connected precondition? Fair. Yes, everything has to be connected, and (currently) also in the same tree-scope
15:35	<annevk>	If disconnected move is not supported you can ignore that caveat.
15:35	<Noam Rosenthal>	and in disconnected case there would be no callbacks at all It would throw an error if you try to move something disconnected
15:36	<annevk>	I think I'd still argue for the same general design for consistency, even if some cases are not supported (atm).
15:36	<Noam Rosenthal>	it would be nonsensical anyway, the iframe etc. is not loaded
15:37	<annevk>	It's more a matter of consistency, but it seems totally reasonable to not support disconnected cases for now (and potentially ever).
15:44	<annevk>	Noam Rosenthal: Going back to your earlier question. I think the default implementation calling the other callbacks is probably fine. I suspect the main feedback is that it should be called `connectedMoveCallback` to match the existing callback naming and that it should have two arguments.
15:46	<Noam Rosenthal>	Noam Rosenthal: Going back to your earlier question. I think the default implementation calling the other callbacks is probably fine. I suspect the main feedback is that it should be called `connectedMoveCallback` to match the existing callback naming and that it should have two arguments. That's SGTM. So `connectedMoveCallback(oldAncestor, newAncestor)` that defaults to `disconnectedCallback(); connectedCallback()`
15:46	<Noam Rosenthal>	Dominic Farolino: ^^
15:47	<Noam Rosenthal>	I think the main thing left on the overflow agenda with this is whether we send `focusin`/`focusout` events as a result and similarly `selectionchange`
15:53	<annevk>	Hmm, smaug do we perhaps only need oldAncestor? It seems like connectedCallback isn't given any argument today. disconnectedCallback isn't either.
15:54	<smaug>	ah, true, disconnectedCallback doesn't know it. connectedCallback can check the new ancestor tree
15:54	<Noam Rosenthal>	`attributeChangedCallback` does, this is perhaps a bit like `ancestorChangedCallback`
15:54	<smaug>	we could always add it later if needed
15:55	<annevk>	So no arguments then. Makes sense.
15:55	<Noam Rosenthal>	Yea starting simpler and extending later is reasonable
16:24	<Dominic Farolino>	Just catching up on the moveBefore() stuff (currently in different breakout session). Yeah, I'd prefer sticking with a connected precondition. One question is, do we need a same-tree scope precondition? We've started with this since crossing shadow dom barriers just "seemed" tricky, but i'm not sure there's a real argument for preventing this.
16:33	<annevk>	Dominic Farolino: I've been assuming same-shadow-including document. So from my perspective that would be fine/preferred.
16:33	<annevk>	Or same-shadow-including root that is a document.
16:50	<Dominic Farolino>	annevk: So it sounds like you're OK removing this condition
16:50	<Dominic Farolino>	https://whatpr.org/dom/1307.html#dom-node-movebefore:~:text=this%E2%80%99s%20root%20is%20the%20same%20as%20node%E2%80%99s%20root
16:50	<Dominic Farolino>	Or no, not removing it but expanding it to cross the shadow boundary. I think i'm fine with that
17:05	<annevk>	Yeah, make it shadow-including root