| 00:14 | <sideshowbarker> | Andreu Botella (he/they) what should we make it say instead? |
| 00:15 | <Andreu Botella (he/they)> | Why not "#whatwg, Matrix" or something similar |
| 01:26 | <DerekNonGeneric> | #whatwg:matrix.org |
| 01:29 | <DerekNonGeneric> | or bizarro world if keeping the sense of logic at the door theme |
| 02:17 | <sideshowbarker> | hmm, seems like it now won’t let me change it to anything that’s no an actual place on map |
| 02:18 | <sideshowbarker> | I guess it does client-side input validation now that it didn’t do before |
| 02:18 | sideshowbarker | tries to see if he can hack around it |
| 02:21 | <sideshowbarker> | yeah it’s not persisting the change even after I change it directly in the DOM |
| 02:30 | <sideshowbarker> | OK, changed it using the API |
| 02:30 | <sideshowbarker> | I changed it to https://matrix.to/#/#whatwg:matrix.org |
| 02:31 | <sideshowbarker> | if others think it should be #whatwg:matrix.org instead, lemme know |
| 02:32 | <sideshowbarker> | hmm, I see it still tries to hyperlink it to something on Google Maps |
| 02:33 | <sideshowbarker> | and for whatever reason, https://matrix.to/#/#whatwg:matrix.org ends up resolving to “Software Lab 5 | do it green” in Wannweil |
| 02:35 | <sideshowbarker> | ah I see that’s because that company has its own location set to matrix.to (or as specific matrix.to address) |
| 02:43 | <DerekNonGeneric> | lgtm |
| 03:11 | <DerekNonGeneric> | sideshowbarker: did you have to use the api to change it to #whatwg:matrix.org? |
| 03:25 | <sideshowbarker> | sideshowbarker: did you have to use the api to change it to |
| 03:31 | <DerekNonGeneric> | wow, that is such a hassle |
| 03:33 | <DerekNonGeneric> | sideshowbarker: i need to do this for my own org and would <3 it if you could share the curl command you used |
| 03:36 | <sideshowbarker> | sideshowbarker: i need to do this for my own org and would <3 it if you could share the curl command you used |
| 03:40 | <DerekNonGeneric> | thanks, worked :) |
| 06:43 | <annevk> | Oh wow, over a 100 people here now, welcome all! 👋🏻 |
| 06:48 | <annevk> | Karl: yeah, for file: URLs some implementations have other types of origins (reading backlog) |
| 07:04 | <annevk> | bakkot: did you see https://github.com/lucacasonato/proposal-binary-encoding? Luca Casonato did you see https://github.com/tc39-transfer/proposal-arraybuffer-base64? |
| 07:20 | <bakkot> | annevk: yeah, see https://github.com/tc39-transfer/proposal-arraybuffer-base64/issues/4 |
| 07:40 | <DerekNonGeneric> | impressive that such an issue was opened (was still feeling things out over at tc39) |
| 07:43 | <DerekNonGeneric> | my suggestion to Luca Casonato is to not propose anything there until Q1 2022 |
| 07:44 | <DerekNonGeneric> | (let alone transfer a proposal repo) |
| 07:46 | <jgraham> | Oh wow, over a 100 people here now, welcome all! 👋🏻 |
| 08:48 | <sideshowbarker> | annevk: https://github.com/mdn/content/issues/7026 is accurate?
|
| 08:50 | <sideshowbarker> | ah https://stackoverflow.com/questions/22747068/is-there-a-max-number-of-arguments-javascript-functions-can-accept is about “Is there a max number of arguments JavaScript functions can accept?” in general |
| 08:51 | <Luca Casonato> | Yeah, I think V8's max 2^16 |
| 08:54 | <sideshowbarker> | yeah it seems surprising for real code to be hitting that limit |
| 08:54 | <sideshowbarker> | maybe Spidermonkey has a much lower limit |
| 08:55 | <sideshowbarker> | so my next question is, does the change in https://github.com/mdn/content/pull/7027/files seem like a reasonable way to work around the limit? |
| 08:55 | <Luca Casonato> | I dislike the use of reduce(). I think it would be a lot more readable with another for loop. |
| 08:56 | <sideshowbarker> | hmm yeah |
| 08:56 | <sideshowbarker> | I’ll add a comment |
| 08:56 | <sideshowbarker> | thanks! |
| 08:56 | <Luca Casonato> | no problem :-) |
| 09:03 | <DerekNonGeneric> | Luca Casonato: not sure how important it is to you, but... |
| 09:03 | <DerekNonGeneric> | Also fwiw tcq2 built on fluid framework should be out q1 2022 |
| 09:03 | <DerekNonGeneric> | source: https://matrixlogs.bakkot.com/TC39_General/2021-06-24 |
| 09:06 | <DerekNonGeneric> | the presentation queue currently in use is sorta messed up and their notes taking methodology needs work |
| 09:07 | <Luca Casonato> | TC39 you mean? |
| 09:07 | <DerekNonGeneric> | indeed |
| 09:08 | <Luca Casonato> | The base64 proposal for TC39 is bakkot's. My alternative is proposed as an addition to the HTML spec, not ES: https://github.com/lucacasonato/proposal-binary-encoding |
| 09:09 | <Luca Casonato> | The two proposals were opened two weeks from each other, kinda confusing. Mine has a larger scope, and support for more encodings. |
| 09:10 | <Luca Casonato> | I should probably make that clear in the explainer |
| 09:11 | <DerekNonGeneric> | hmm, you would need to find a champion (delegate) either way, so bakkot might be your best bet on that |
| 09:11 | <DerekNonGeneric> | w/o having looked at the other proposal you mentioned, i wonder if a merger would be a good idea or not |
| 09:12 | <Luca Casonato> | Maybe yeah - I would want to slightly expand the scope of the TC39 proposal. The main differentiator is that my proposal allows for easier future extensions, and streaming support. |
| 09:13 | <annevk> | To be clear, you don't need a TC39 delegate for HTML spec additions; WHATWG has its own process |
| 09:16 | <DerekNonGeneric> | what is considered a "proposal" to tc39ers is a bit of a mystery to me, but my intention wasn't to delay |
| 09:17 | <DerekNonGeneric> | apparently, they only consider something a "proposal" if a delegate has it on their agenda |
| 09:18 | <Luca Casonato> | I don't think the WHATWG has any strict definition of "proposal". I think anything with an open issue on an existing spec or an explainer is considered a proposal. The bar is pretty low. |
| 09:25 | <DerekNonGeneric> | not sure which org would be best for either of the proposals mentioned, but be able to help w/ nodejs impl |
| 09:25 | <DerekNonGeneric> | if node is currently misaligned, let me know and we see about getting that fixed if its not a huge PITA |
| 09:35 | <DerekNonGeneric> | we currently have a few dependencies in our repo vendored in from elsewhere, so it might be as simple as adding the streaming cryto dependency to our source tree |
| 09:36 | <DerekNonGeneric> | we would expose it through V8, but don't necessarily need to wait for stage advancement in tc39 and such |
| 09:40 | <DerekNonGeneric> | the main advantage to the whole proposal-stage-etc stuff is being able to collect feedback from smart ppl |
| 10:01 | <DerekNonGeneric> | (that's just node though) |
| 10:02 | <sideshowbarker> | annevk: about https://github.com/mdn/content/issues/6970 |
| 10:02 | <sideshowbarker> | …I’m trying to figure out what wording to add to https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams/URLSearchParams#parameters |
| 10:04 | <Luca Casonato> | sideshowbarker: It actually doesn't explicitly accept FormData. FormData just happens to be an iterator that conforms to sequence<sequence<USVString>> which URLSearchParams can accept (so it is webidl converted). |
| 10:05 | <sideshowbarker> | Luca Casonato: right but it’s kind of an important instance of “just happens to be” |
| 10:06 | <Luca Casonato> | Ah sure. In that case maybe - A sequence of USVString pairs, representing names/values. This includes `FormData` objects.? |
| 10:06 | <Luca Casonato> | Or just demo it in an example? |
| 10:06 | <Andreu Botella (he/they)> | In any case, a mention of FormData should note that File entries will be serialized as [object File] rather than as their filename as they would in an application/x-www-form-urlencoded form |
| 10:07 | <sideshowbarker> | Ah sure. In that case maybe |
| 10:07 | <annevk> | sideshowbarker: sounds similar to that other case where URL "is accepted" because it stringifies |
| 10:07 | <sideshowbarker> | annevk: right |
| 10:07 | <annevk> | sideshowbarker: you prolly want to establish some kind of pattern in terms of wording |
| 10:08 | <sideshowbarker> | yeah I guess I should be consistent |
| 10:10 | <sideshowbarker> | anyway I guess this one to me seems a bit exceptional in that it really is the common case rather than the case of giving URLSearchParams some name/value pairs in some other way |
| 10:10 | <sideshowbarker> | or maybe that’s just me |
| 10:13 | <sideshowbarker> |
…is how I previously worded the stringifier case |
| 10:13 | sideshowbarker | will write up a PR with similar wording for this |
| 12:43 | <annevk> | That sounds good to me, FWIW |
| 12:44 | <annevk> | sideshowbarker: writing that down I realized what I now see Andreu Botella (he/they) already noted above, Blob/File inside FormData will behave unexpectedly and it should probably mention that |
| 12:45 | <sideshowbarker> | yeah I will add that |
| 15:07 | <annevk> | jgraham: foolip: shall I update https://github.com/whatwg/sg/pull/164 to say Test Utils? |
| 15:08 | <annevk> | And now https://www.w3.org/2021/06/WHATWG-W3C-MOU_2021_update.html is published (yay!) I guess we should also work on a PR for Web IDL |
| 15:33 | <annevk> | If anyone has questions about that let me know, but it basically formalizes a number of things that were already in motion. And as it happens making things formal after the fact can take a lot of time. |
| 15:33 | <Andreu Botella (he/they)> | I noticed the webidl branch on sg a while ago, and I was wondering what took it so long |
| 15:36 | <jgraham> | annevk: I'm happy for you to update it. |
| 15:44 | <annevk> | Andreu Botella (he/they): for reference, adding a one-sentence copyright line to Web Applications 1.0 (former name of HTML) took six months |
| 15:52 | <bakkot> | the presentation queue currently in use is sorta messed up and their notes taking methodology needs work |
| 16:41 | <DerekNonGeneric> | (hoping to drive innovation here, not argue) am looking forward to all suggestions that were mentioned (having the queue use a publicly-visible representation i.e., sheets) would help |
| 16:58 | <DerekNonGeneric> | bakkot, here is what i was referring to when i was commenting about the upgrade path |
| 16:58 | <DerekNonGeneric> | https://developers.google.com/sheets/api/reference/rest |
| 17:02 | <DerekNonGeneric> | the point that was mentioned by Rob about the history tracking offered by Docs was also key |
| 17:02 | <DerekNonGeneric> | https://developers.google.com/docs/api/reference/rest |
| 17:05 | <DerekNonGeneric> | being placed on the queue by the bot sounded interesting as well, but not trying to tell you how to run the show, just wanted to point out that a lot of good advice was provided and would like to see it materialize |
| 17:09 | <annevk> | DerekNonGeneric: prolly best to take that to #tc39-general:matrix.org or some such |
| 17:10 | <DerekNonGeneric> | yeah, agreed, getting back on-topic sounds good -- am totally in the dark about WHATWG processes too lol |
| 17:16 | <DerekNonGeneric> | going to have to do my research i guess, but if anyone wants to link how proposals work here, i will bookmark it for later seeing as how i am a bit busy writing a specification for something else (still just a UI) |
| 17:29 | <DerekNonGeneric> | would be curious to know how one goes about writing something like the worklets specification https://html.spec.whatwg.org/multipage/worklets.html#worklets |
| 17:40 | <Domenic> | https://whatwg.org/faq#adding-new-features is probably the right place to start |
| 17:41 | <annevk> | And https://whatwg.org/working-mode |
| 17:42 | <annevk> | Domenic: so it could be I don't understand BYOB, but I thought at a high-level the concept was that the web developer would create a buffer + view, and the API would write data into that |
| 17:42 | <annevk> | Domenic: so what I don't understand in your PR is that there's a step where the API creates a buffer + view, when the size isn't sufficient |
| 17:55 | <Domenic> | annevk: the idea is that if your underlying source (i.e. network APIs) support it and the buffer is big enough, you write into it. E.g. for filesystem APIs were you can explicitly control how many bytes you request this works great. For network APIs you can't always control; flow control takes a while to propagate through TCP. So in that case we might have too many bytes to fit into the buffer. |
| 17:57 | <Domenic> | In actuality you wouldn't need to create any JS ArrayBuffer objects like the spec does so you do save a couple of mini-allocations. And since it's all hidden behind transferrability you could avoid copying in favor of slicing up memory regions and making making the new view point to the original region. But there's no way to write 64 KiB of data from the network into a 1 KiB developer-supplied buffer. |
| 17:58 | <annevk> | Maybe my confusion stems from the specification using JS views and buffers |
| 17:59 | <annevk> | Domenic: how does it work if you do read(largeView) and the network is slow? You have to wait a long time? |
| 17:59 | <Domenic> | annevk: no in that case you get back your buffer with however many bytes were available and a view onto only the bytes that were written into it |
| 18:00 | <Domenic> | https://github.com/whatwg/streams/pull/1145 is a proposal for the "wait a long time" variant, which in some cases might be convenient. |
| 18:00 | <annevk> | Ah okay, so you basically get each chunk or however many chunks a UA decides to combine |
| 18:01 | <annevk> | And the API is a bit different from encodeInto in that it returns a view |
| 18:01 | <Domenic> | Hmm yeah I never thought to compare with encodeInto |
| 18:01 | <annevk> | In principle you only need to know how much was written, right? |
| 18:02 | <Domenic> | You also need to know the new ArrayBuffer object identity (same backing memory) since it went through a transfer dance |
| 18:03 | <annevk> | Aah, thanks. I think I understand it a bit better now. I'll look into the queuing thing tomorrow I suspect, unless a lot of other things pile up. |
| 18:04 | <Domenic> | np, no rush on any of this I don't think |
| 18:04 | <Domenic> | It's slightly more near-term-relevant than it used to be because WebTransport is my impression. |
| 18:07 | <Domenic> | https://twitter.com/nevali/status/1416107137714040845 I can get behind this |
| 18:19 | <timothygu> | annevk: what would the process be like for publishing review drafts for IDL? Would the editors be responsible for that or do you usually publish the RDs for all the specs |
| 18:21 | <annevk> | timothygu: we'd handle it automatically through review.py in whatwg/meta |
| 18:21 | <annevk> | timothygu: which effectively comes down to me / foolip / Domenic |
| 18:22 | <annevk> | If there's a build error in the main file it might involve you though |
| 18:22 | <timothygu> | great! sounds good |
| 21:20 | <Luca Casonato> | This might have been one of the fastest turnarounds for a new spec addition in a while: https://github.com/w3c/webcrypto/pull/266. Added to Chrome, Firefox, Safari, Deno and Node in only 17 days. Already shipped in latest stable Deno release. |
| 21:20 | <Luca Casonato> | Granted it is a tiny addition and change, but still good to see. |
| 22:37 | <bakkot> | glad to see webcrypto getting some love again! |