| 07:13 | <Ms2ger> | HTML says "This specification does not specify which image types are to be supported." |
| 08:03 | <Pierre-Yves Gérardy> | Hi folks, coming here from https://github.com/whatwg/dom/issues/586 per @annevk's suggestion |
| 08:04 | <Pierre-Yves Gérardy> | The proposed API looks to me like a "better horse" situation, hence my comments... |
| 08:07 | <annevk> | Pierre-Yves Gérardy: hey welcome, thanks for joining! And thanks for giving feedback, but note that for effective participation it's usually better to support an existing comment that says as much or leave a single comment that clearly makes your point. Adding a lot of comments to an issue will make them look noisy and more easily ignorable. |
| 08:08 | <annevk> | And to be clear, the API as proposed wouldn't make it in. If we actually want CSS parity it would need move semantics as discussed in the issue I linked. |
| 08:17 | <Pierre-Yves Gérardy> | Move semantics... could you explain? As in not detaching the nodes from the document/parent while moving them around? If so I'm with you from my first comment on... |
| 08:19 | <Pierre-Yves Gérardy> | Losing the state of media elements, iframes, and the focus when moving nodes is an anti-feature of the current DOM methods. |
| 08:30 | <Pierre-Yves Gérardy> | A single parent.spliceChildren(nodes: Nodes[], {previousSibling?, nextSibling?, delayRemoval?: (n:Node)=>Promise) method would cover all the cases used in the wild in frameworks AFAIK, and would be more ergonomic than asking users to tag nodes with an attribute for the browser to reorder |
| 08:32 | <annevk> | Pierre-Yves Gérardy: right, at the moment the DOM only has insert, remove, and replace all, essentially. |
| 08:32 | <annevk> | That signature looks more complex than what I had in mind, but there's a lot of pre-requisites to sort out first anyway. (As noted in my comment.) |
| 08:39 | <Pierre-Yves Gérardy> | Do you mean https://github.com/whatwg/dom/issues/808? |
| 08:49 | <Pierre-Yves Gérardy> | Re. signature, (nodes, options?) has the advantage of future extensibility. For the simple case(reorder all nodes) the options are not needed. If you want to move a subset of nodes from one point to another, it becomes splice(nodes, splicePoint) which is as convenient as it gets... |
| 08:49 | <annevk> | What would prevent us from adding a dictionary when we need it? |
| 08:50 | <Pierre-Yves Gérardy> | The modern DOM methods are variadic |
| 08:51 | <annevk> | Those could still have a dictionary at the end if we wanted to. And yeah, that issue is a pre-requisite. The other issue that's referenced discusses move semantics. |
| 08:59 | <Pierre-Yves Gérardy> | In my ideal world, moving nodes within a document wouldn't tigger a state teardown/init if done atomically. A manual Could these APIs be extended to accept arrays of nodes, so that we don't have to splice them in? That would avoid iterating twice over the list. |
| 09:13 | <Pierre-Yves Gérardy> | They already do, my bad :-) |
| 09:17 | <Pierre-Yves Gérardy> | Actually, they don't, and can't be updated for Web compat reasons I guess, since arrays are stringified :-/ |
| 09:24 | <annevk> | Pierre-Yves Gérardy: you can use apply, it's fine |
| 09:28 | <Pierre-Yves Gérardy> | And push the options at the end of the array if they ever were supported I suppose. 👍️ Re. #808 why can't we add methods that don't trigger the state reinitialization when moving within the same document? Wouldn't that give us the CSS parity you're after? |
| 09:28 | <Pierre-Yves Gérardy> | ... and side-step #808 altogether |
| 09:29 | <annevk> | In order to understand what you can ignore, you first have to understand what you will be ignoring. |
| 09:30 | <Pierre-Yves Gérardy> | :-) Gotcha, I'll read more about it and come back. Thanks for your patience |
| 09:35 | <sideshowbarker> | Is this use of the term “move semantics” inspired by the same concept from C++? And is it some new usage? I don’t so that term anywhere in the DOM spec itself yet… |
| 09:44 | <annevk> | sideshowbarker: maybe? The idea is that you wouldn't remove or insert a node (current primitives), but move it. This would also result in a different mutation record, for instance. |
| 09:50 | <sideshowbarker> | I see. I asked just because I’ve not ever seen “move semantics” used in a general sense for anything, and because it have a very specific specialized meaning in C++. I would think that C++ programmers might find the use of the term for DOM operations to be a bit odd — or that it might imply to them some special behavior similar to what it has in C++. But maybe not. I guess Rust uses the term, though I think Rust uses in much the same way that C++ does. Anyway, was just curious |
| 09:58 | <Pierre-Yves Gérardy> | @annevk are MutationEvents still a concern in 2023? If so, move semantics could be spec'ed such that mutation events throw errors. That would be Web compatible, and would push folks who still use MutationEvents and want to opt into move semantics to migrate away from them. |
| 10:05 | <Pierre-Yves Gérardy> | A gentler option would be to ignore the mutation events and issue warnings. |
| 10:40 | <annevk> | sideshowbarker: it's not quite "general sense" though :-) it's in the context of the node tree |
| 10:42 | <annevk> | Pierre-Yves Gérardy: mutation events still exist and will be a problem of sorts, but they're not the main problem I think |
| 10:42 | <Pierre-Yves Gérardy> | Yes, I'm reading through the various issues listed in #808 |
| 10:44 | <Pierre-Yves Gérardy> | I was just wondering if throwing bones at folks that still use them was deemed fair game if we don't break existing sites |
| 10:44 | <annevk> | I'm not quite sure what that means. It sounds like it would make event listeners observable which seems bad. |
| 10:48 | <Pierre-Yves Gérardy> | Because one can spy on console.warn? The warning could be issued asynchronously... |
| 10:49 | <Pierre-Yves Gérardy> | By "throwing a bone", I mean creating features that are deliberately incompatible with the ones you want to deprecate. |
| 10:50 | <annevk> | Yeah sure, I suspect we might do that. Again, not the biggest issue. |
| 10:56 | <Pierre-Yves Gérardy> | I see, the race conditions described in #808 and friends look "fun" |
| 11:13 | <Pierre-Yves Gérardy> | Regarding these issues, is there a notion of atomic transactions in DOM operations? As in "no user code runs during a DOM transaction"? |
| 11:14 | <annevk> | Nope |
| 11:15 | <Pierre-Yves Gérardy> | That sounds like a useful concept to tie these issues together |
| 11:17 | <Pierre-Yves Gérardy> | I don't mean exposing the concept to user code, but relying on it to define DOM operations in the spec |
| 11:20 | <annevk> | It wouldn't help with move. The problem isn't userland. The problem is with element-specific behavior (some of which potentially needed). |
| 11:24 | <Pierre-Yves Gérardy> | So far the issues I've seen are about code within script tags that runs before its siblings are present. I've yet to dig into the iframe issues |
| 11:24 | <annevk> | It's not even clear to me you can completely avoid trashing animations as selectors will end up matching different nodes so some amount of invalidation will be needed. |
| 11:25 | <annevk> | Pierre-Yves Gérardy: well that's a thing that happens when you insert script. We probably don't have to invoke those callbacks when we move. (But in order to be sure we better first understand insert.) |
| 11:41 | <Pierre-Yves Gérardy> | I supposed as much re. script insertion. Who's the "we" that should better understand insertion and removal? The WhatWG? Implementers? Both? In any case, is there something I can do that would help? Animations are another can of worms, yes :-). If we allow to move nodes across parents, I suppose that the |
| 11:44 | <annevk> | Pierre-Yves Gérardy: the last time I looked at that browser behavior differed. It's also not specified. Getting it properly specified and agreed upon would be a good first step. |
| 12:07 | <zcorpan> | I think I'll stop using "good first issue" labels. It seems it mostly accomplishes getting comments saying "please assign to me", but no PRs |