06:24
<sideshowbarker>
annevk: https://github.com/whatwg/html/pull/9546/files#r1879416670
07:55
<annevk>
Dominic Farolino: there's also pre-removing steps. Should that be pre-remove steps then?
07:57
<annevk>
sideshowbarker: there's an open issue on standardizing [Reflect] and I think we're pretty close after the refactoring I did on reflection a while back, but not quite there yet
10:08
<Jake Archibald>

annevk Domenic: Atomics & SAB let you 'sleep' workers waiting something, but that requires an isolated origin, and it's not trivial to pack data into an SAB. Could message ports have a postMessage type thing that synchronously waits for a response from the other side? Like atomics, the sleeping side must be a worker.

API sketch:

In a worker:

console.log(
  self.postSyncCall({ action: 'sum', numbers: [2, 2] })
);

…logs 4.

In a page:

worker.addEventListener('synccall', (event) => {
  if (event.data.action === 'sum') {
    event.respondWith(async () => {
      const result = await someAsyncMathsSupercomputer.sum(event.data.numbers);
      return result;
    });
  }
});

Is this is stupid idea?

10:08
<Jake Archibald>
Our usecase is a DOM polyfill in a worker, and in some cases we want getters to get their result from some other thread
10:12
<sideshowbarker>
HTML spec issue, or WebIDL issue? I looked in both places, but didn’t manage to find what I was looking for…
10:59
<annevk>
sideshowbarker: https://github.com/whatwg/html/issues/3238
10:59
<annevk>
Jake Archibald: has the same kind of issue as any kind of sync API proposal, but maybe it's considered more reasonable these days for dedicated workers to block on something?
11:01
<Jake Archibald>
annevk: Maybe? Atomics.wait() certainly does that
12:36
<annevk>
Jake Archibald: yeah and there's also synchronous file reading.
12:37
<Jake Archibald>
Although, an async version of the above would be somewhat useful too. Easy to have both I guess
14:01
<annevk>
Jake Archibald: oh you mean postMessage() but instead it returns? Yeah maybe.
14:02
<Jake Archibald>
annevk: It might need to be another method, but yeah, like postMessage but returns Promise<something>, which is a clone of whatever was passed to respondWith on the other side
14:20
<annevk>
Reusing respondWith() could be interesting too. Much less API surface to add.
15:56
<Dominic Farolino>
Renamed to topic: frames/navigables/browsing contexts (apparently commas are illegal?
15:57
<Dominic Farolino>
Figured we didn't need "iframes" and "frames" to be enumerated, and the previous label name is "browsing contexts" which seems find to preserve
16:04
<Dominic Farolino>
I suppose. I feel like this kind of renaming is usually the sort of thing you ask for in a follow-up. Do you want me to do all the renaming in the moveBefore() PR?
16:31
<annevk>
It's probably better as a separate PR, yes.
16:33
<Dominic Farolino>
annevk: Should I revert https://github.com/whatwg/dom/pull/1307/commits/5c87649e6ac3475589220ad72e0e59855d2eb636 then?
16:55
<annevk>
If you make the other PR then it'll just disappear all on its own.