| 00:45 | <MikeSmith> | TabAtkins: I think sjamaan was referring to the WHATWG Participant Agreement |
| 00:46 | <TabAtkins> | Ah! |
| 00:48 | <MikeSmith> | TabAtkins: btw given a particular spec, if there were a (relatively) easy way to get data about MDN articles that have links to parts of that spec, would be be supportive of adding a mechanism to to Bikeshed that inserted MDN annotations in spec output? |
| 00:49 | <TabAtkins> | Yes. Same as the caniuse data. |
| 00:49 | <MikeSmith> | cool |
| 00:50 | <MikeSmith> | the bad news is that there currently is no easy way to get the data; MDN doesn’t expose any API for it (nor really any APIs at all) |
| 00:51 | <MikeSmith> | the better news is that I raised https://discourse.mozilla.org/t/proposal-have-mdn-api-provide-data-for-all-specs-linked-to-in-specifications-tables/31768 to propose that something be added |
| 00:52 | <MikeSmith> | sjamaan: see the discussion at https://github.com/whatwg/sg/issues/84 |
| 00:53 | <MikeSmith> | from Google’s rep on the WHATWG steering group, latest comment (from a month ago) is at https://github.com/whatwg/sg/issues/84#issuecomment-413366864 |
| 00:53 | <MikeSmith> | > The SG is considering this issue and we will, at the least, work on a detailed FAQ that would clarify the language and help make quicker decisions in such situations. We are getting legal counsel and will report back on this, as soon as possible. |
| 06:33 | <davedoesdev> | hi |
| 06:34 | <davedoesdev> | I'm trying to pass a ReadableStream as the body of a fetch POST request |
| 06:36 | <davedoesdev> | (Chrome) However, nothing is read from the stream and "[object Object]" is sent |
| 06:40 | <davedoesdev> | Regarding the API, should this work? |
| 06:40 | <davedoesdev> | https://www.irccloud.com/pastebin/jh8rOYve/ |
| 06:53 | <davedoesdev> | I see it's not supported yet in browsers (https://developer.mozilla.org/en-US/docs/Web/API/Request/Request) |
| 06:56 | <sjamaan> | MikeSmith: Thanks for the link. Seems it isn't exactly clear yet :S |
| 09:05 | <annevk> | sjamaan: basically, when in doubt, try to get your employer to sign it, as it'll be less hassle |
| 09:05 | <annevk> | sjamaan: less of a waiting period anyway |
| 09:05 | <sjamaan> | hm, ok, I'll ask around |
| 09:06 | <annevk> | sjamaan: we're trying to get it clarified, but I'm not expecting things to change around quickly |
| 09:06 | <annevk> | sjamaan: it took 1.5y to get this thing off the ground to begin with... |
| 09:06 | <sjamaan> | yikes |
| 09:11 | <Ms2ger> | And that was after what, nine years of trying to avoid setting it up? :) |
| 09:11 | <sjamaan> | heh |
| 09:31 | <MikeSmith> | ''] |
| 09:31 | <MikeSmith> | ']]' |
| 09:31 | <MikeSmith> | \' |
| 09:32 | <MikeSmith> | \ |
| 09:33 | <MikeSmith> | \A |
| 09:56 | <MikeSmith> | \A[=] |
| 10:06 | <lgrahl> | Dropping this here for you to perhaps share (because I know some of you've already added their two cents): https://discourse.wicg.io/t/streams-for-the-proposed-webrtc-quic-api/3035 |
| 14:11 | <devsnek> | isn't quic dead by http2 and tls 1.3 |
| 14:18 | <lgrahl> | Perhaps for serving web pages. But none of them are usable for RTC. |
| 14:20 | <Ms2ger> | Can anyone merge https://github.com/heycam/webidl/pull/577 ? |
| 14:20 | <Ms2ger> | TimothyGu? |
| 14:20 | <Ms2ger> | Domenic? |
| 14:20 | <Ms2ger> | annevk? |
| 14:23 | <annevk> | Ms2ger: as rebase & merge? |
| 14:24 | <Ms2ger> | annevk, yes please, and thank you |
| 14:24 | <annevk> | Hmm, it doesn't quite meet the commit message guidelines... |
| 14:25 | <annevk> | And I don't know if those are enforced for IDL |
| 14:26 | <annevk> | I'll ping Domenic |
| 14:55 | <Ms2ger> | "Allow edits from maintainers." is on if so |
| 15:14 | <annevk> | Ms2ger: if there's still nobody caring tomorrow I'll make it happen (maybe after another ping) |
| 15:14 | <Ms2ger> | Thanks |
| 20:54 | <Domenic> | lgrahl: this kind of thing should come up in TAG review; not sure if those people have filed for that yet or not |
| 21:26 | <JKingWeb> | Okay, I see what's going on with the EUC-JP decoder test now, at least: the test harness uses the expectations in the test data only for display, with the actual expectations being the output of a reference implementation. That explains with browsers pass, and it just means that the test data are a bit stale. |
| 21:34 | <lgrahl> | Domenic: Found an issue: https://github.com/w3ctag/design-reviews/issues/303 |
| 21:45 | <lgrahl> | Domenic: Martin Thomson already mentioned the streams API in that issue. Hopefully they'll pick it up in a review. |
| 21:46 | <lgrahl> | Thanks for mentioning TAG. (I actually didn't know anything about them...) |