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> |
Responded to this on the spec PR thread |
11:35 | <annevk> | Ah, that doesn't sound unreasonable. I was thinking some more about overloading |
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> |
|
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 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. |
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 |
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(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 |