00:39
<bakkot>

streams question:

(async () => {
  let stream = new ReadableStream(
    {
      start(controller) {
          controller.enqueue(Promise.resolve(0)); // NOTE: enqueuing a promise
          controller.close();
      },
    },
  );
  for await (let item of stream) {
    console.log({ item });
  }
})();

(Streams are async iterable as of https://github.com/whatwg/streams/pull/980, though only FF has implemented as far as I know.)

Here, should the console.log be of 0 or of a Promise for 0? If I'm reading the various specs right, it should be a Promise. FF has it as an actual 0. The original conversation about async iterators which yield promises (in the iterator result object) decided that it should be considered a contract violation to do so - see slide 27 of https://docs.google.com/presentation/d/1U6PivKbFO0YgoFlrYB82MtXf1ofCp1xSVOODOvranBM/edit#slide=id.g223fba4116_0_196

this is really an edge case, so maybe the "contract violation" is fine? it's not like the language enforces that contract. but if the intent is that it should be a Promise for 0, that probably warrants a WPT

00:58
<Alexander Kalenik>
a document loading question: https://html.spec.whatwg.org/multipage/document-lifecycle.html#read-ua-inline step 3 assumes there is "response" from which URL can be obtained but "response" is not listed in the parameters. step 4 initialize navigationParams params with newly created response but step 5 that creates document using these navigationParams seems to assume that response always has non-empty URL. am I missing something or there is a bug that "Loading a document for inline content that doesn't have a DOM" should accept url?
01:00
<Domenic>
a document loading question:

https://html.spec.whatwg.org/multipage/document-lifecycle.html#read-ua-inline
step 3 assumes there is "response" from which URL can be obtained but "response" is not listed in the parameters.
step 4 initialize navigationParams params with newly created response but step 5 that creates document using these navigationParams seems to assume that response always has non-empty URL.

am I missing something or there is a bug that "Loading a document for inline content that doesn't have a DOM" should accept url?
Looks like a bug to me. I think we can just use about:blank though instead of passing in a URL.
01:01
<Domenic>

streams question:

(async () => {
  let stream = new ReadableStream(
    {
      start(controller) {
          controller.enqueue(Promise.resolve(0)); // NOTE: enqueuing a promise
          controller.close();
      },
    },
  );
  for await (let item of stream) {
    console.log({ item });
  }
})();

(Streams are async iterable as of https://github.com/whatwg/streams/pull/980, though only FF has implemented as far as I know.)

Here, should the console.log be of 0 or of a Promise for 0? If I'm reading the various specs right, it should be a Promise. FF has it as an actual 0. The original conversation about async iterators which yield promises (in the iterator result object) decided that it should be considered a contract violation to do so - see slide 27 of https://docs.google.com/presentation/d/1U6PivKbFO0YgoFlrYB82MtXf1ofCp1xSVOODOvranBM/edit#slide=id.g223fba4116_0_196

this is really an edge case, so maybe the "contract violation" is fine? it's not like the language enforces that contract. but if the intent is that it should be a Promise for 0, that probably warrants a WPT

I think it'd be best if Web IDL enforced that such cases get unwrapped, like (IIRC) the relevant ES machinery does.
01:02
<bakkot>
there's not much ES machinery, but the closest things are async generators manually yielding promises, and for-await over sync iterator of promises as in for await (let item of [Promise.resolve(0)]) ..., both of which do indeed unwrap
01:03
<Domenic>
Yes, this feels analogous to async generators manually yielding promises
01:04
<bakkot>
unfortunately unwrapping means you have to await every value, which is kind of annoying. maybe there can be a check to see if the type of the iterator could be something await-able, so it's only in generic cases like the ReadableStream ctor rather than having to pay the cost of awaiting for all async iterables? but on the other hand maybe not worth trying to optimize away the extra await.
01:04
<bakkot>
anyway, I'll open a webIDL issue
01:15
<bakkot>
done: https://github.com/whatwg/webidl/issues/1288
01:15
<bakkot>
(also added an edge case around error handling which occurred to me while writing it.)
04:56
<bakkot>
ah, turns out I misread the streams spec and in fact it already unboxes (or rather, to be precise, the "get the next iteration result" algorithm is phrased in terms of a promise resolved with enqueued value, so it'll flatten promises)
05:20
<bakkot>
there is, alas, still a bug around the handling of rejected promises - https://github.com/whatwg/streams/issues/1266
07:33
<annevk>
Hmm, the Encoding Standard has a lot of "lead X"
14:22
<roman harsveld>
i like to learn to build my own websites but have no have no idea where I can learn html i try html standard for learn
16:37
<annevk>
hsivonen: mfreed: https://github.com/html5lib/html5lib-tests/pull/163 and https://github.com/html5lib/html5lib-tests/issues/137 would appreciate your review (and that of others interested in the HTML parser)
17:35
<zcorpan>
annevk: Ms2ger : interesting, "in select" vs "in select in table"?
22:23
<Ehsan Azari>
Hi all, how can I record and store event loops as data? Is there any way?
23:12
<TabAtkins>
Hm, is it actually possible to define an interface that inherits from ObservableArray?