00:14
<jugglinmike>
I'm thinking of blending them with the guess that half of the datapoints overlap
01:08
<Domenic>

annevk: I finally found some corroboration for my belief that "e.g." doesn't always need a comma after it: https://www.grammarly.com/blog/know-your-latin-i-e-vs-e-g/ talks about how it's important to add a comma when introducing a list of examples, but (implicitly) not for a single example. Also https://english.stackexchange.com/questions/16172/should-i-always-use-a-comma-after-e-g-or-i-e talks about how all the grammar guides hedge.

That said, I'm happy to settle on consistent and easy-to-remember WHATWG style being always to use the comma. I just wanted to make sure I wasn't crazy.

03:05
<aja>
oxford commas...pick your style guide
06:36
<annevk>
Domenic: oh sorry, I never thought you were wrong. I was mainly trying to keep us consistent with a style someone expressed preference for at some point. 😅
06:39
<krosylight>

Domenic: About the error check after enqueue in Fetch:

r = new ReadableStream({
  async pull(c) {
    await new Promise(r => setTimeout(r, 100));
    c.byobRequest.respond(512);
  },
  type: "bytes"
});
reader = r.getReader({mode: "byob"});
reader.read(new Uint16Array(1024));
setTimeout(() => reader.releaseLock(), 5);

This eventually hits https://streams.spec.whatwg.org/#abstract-opdef-readablebytestreamcontrollerenqueueclonedchunktoqueue which theoretically can error the stream. Can Fetch really ignore this?

09:11
<annevk>
I wonder why the coalescing in popover was duplicated and not factored out, but maybe I can attempt to do that.
09:34
<hsivonen>
smaug: hsivonen: I guess I clean those tests up, and also make the encoding/ tests use <meta> instead for now so we don't run into this particular issue. And then file bugs against Chromium/WebKit or open a spec issue to see if we want to collectively reconsider given that more sites might rely on Chromium/WebKit behavior at this point...
Thanks.
09:37
<hsivonen>
zcorpan: Do you happen to recall history around https://www.w3.org/Bugs/Public/show_bug.cgi?id=25168 ? IIRC, the XMLSerializer API was introduced in Gecko. How did non-Gecko behaviors around bogus XML get introduced? Context: https://bugzilla.mozilla.org/show_bug.cgi?id=1763779
10:35
<zcorpan>
hsivonen: I don't know the history. Guessing that maybe the serializer was only expecting input that has been parsed by an XML parser, and not HTML parser or DOM APIs
10:37
<zcorpan>
hsivonen: I guess that bug depends on what createElement does for that case
10:43
<hsivonen>
hsivonen: I don't know the history. Guessing that maybe the serializer was only expecting input that has been parsed by an XML parser, and not HTML parser or DOM APIs
I'm pretty sure that as introduced in Gecko, XMLSerializer tried hard to skip over bogus stuff that might have been introduced via DOM Level 1 APIs. So where did contrary behavior come from? Anyway, it looks it's now 2 vs. 1 by the way of the 2 being whatever WebKit had before the Blink fork.
10:44
<zcorpan>
:/
11:11
<annevk>
Jonas Sicking might recall the details. Not sure how to reach him though. My impression is that there have always been problematic corner cases.
17:13
<jarhar>
annevk I addressed the pointerevents comment in the popover PR
17:38
<annevk>
jarhar: good morning! Thanks. I'll take a look in a bit and merge it assuming it looks alright
17:38
<annevk>
Don't merge on a Friday and then go on vacation is the typical advice I think, but...
18:08
<annevk>
jarhar: it's in \o/
18:10
<jarhar>
thank you!
20:29
<TabAtkins>
PSA: Bikeshed was moved from my personal account to the speced org, at https://github.com/speced/bikeshed. Docs are now at https://speced.github.io/bikeshed.