WHATWG
2025-02-08
plaintext logs
prev next
source on github
01:29
<sideshowbarker>
There’s a workable alternative to doing that “prepare a script” step there?
03:26
<gingeh>
Maybe a weird question but does anyone here know of an algorithm in a whatwg spec which takes a collection (preferably a list) by reference? I'm just hoping for an example because I'm not sure how it's usually described in spec-speak
04:44
<Domenic>
It's always assumed to be by reference. In general algorithms are JS-ish semantics, with the biggest exception being that strings are often treated as mutable.
04:45
<Domenic>
https://github.com/whatwg/infra/issues/91 for discussion of mutable vs. immutable strings
07:03
<Valery>
I wonder if something like background-image: element() is possible to be a document node type, where I can select a node to be mirrored, so that I can add it to the document, visually, it would behave in the same way, but it doesn't need to be processed once again. All the computations can be reused up to the GPU level. I feel like it should not be so complex since this would be a standalone node, no?
09:45
<Gregory Terzian>

I have a question about this test: "Aborting a WritableStream before it starts should cause the writer's unsettled ready promise to reject" in /streams/writable-streams/aborting.any.js

The test:

  1. acquires a writer on a newly created stream,
  2. then writes on it,
  3. then assigns writer.ready to a variable
  4. and aborts the writer.

After 3, it seems to expect the promise to equal the readyPromise on the writer, and to finally reject with the error passed to abort.

09:53
<Gregory Terzian>

But, it appears to me that the readyPromise would have already been resolved in set-up-writable-stream-default-writer, at step 5.2("Otherwise, set writer.[[readyPromise]] to a promise resolved with undefined.").

Then the promise assigned to the variable at 3 is in fact already resolved, and then the abort call at 4 will end-up calling into ensure-ready-promise-rejected, which replaces writer.readyPromise with a new rejected promise(because the promise is not pending anymore).

On way this would be false would be if the write(or the setup) would reach "If backpressure is true, set writer.[[readyPromise]] to a new promise." of update-backpressure, but this would require backpressure to be true, and the test does not seem to provide any such backpressure other than the default one where the desired size is 1, and then that single write should not trigger backpressure.

The test passes in all implementation, so I'm wondering what I'm missing, or if perhaps the spec was updated to fail the test, and this wasn't reflected in any implementation.

10:01
<Gregory Terzian>
Ok sorry I think I just figured it out, the write adds an item to the queue, so that makes backpressure true because it hits zero.
10:02
<Gregory Terzian>
so the write replaces the promise that was settled in the writer setup, and then the abort rejects it(because it is pending).