| 03:08 | <devsnek> | Domenic: is there a plan to have ReadableStreamDefaultReader be an async iterable in the future? |
| 03:58 | <Domenic> | devsnek: yep, just need to do the work. https://github.com/whatwg/streams/issues/778 |
| 03:59 | <devsnek> | i've never felt so jaded as seeing a series of promises resolve with { value, done } but not be an iterator lol |
| 03:59 | <devsnek> | does this just need spec work? |
| 04:00 | <Domenic> | Yeah and tests |
| 04:00 | <Domenic> | Happy to mentor if you have the time :) |
| 04:06 | <devsnek> | Domenic: sounds fun, just nervous about doing tests |
| 04:06 | <devsnek> | i'm not good at tests |
| 04:07 | <Domenic> | We can make it work :). Maybe collaborate on a test plan (~ list of tests) first? |
| 04:07 | <Domenic> | But, for now, sleep time |
| 04:08 | <devsnek> | 👋 |
| 08:13 | <zcorpan> | Can someone give me editbugs for bugs.webkit.org? hober? |
| 08:20 | <zcorpan> | or maybe I have that already |
| 08:34 | <annevk> | I lost mine for Chromium somehow |
| 15:33 | <Domenic> | Wow great stuff on fieldset, zcorpan. What a mess. |
| 16:21 | <Domenic> | Sometimes I feel the single biggest thing we could do to make HTML contribution easier would be an auto-reformatter. |
| 16:25 | <annevk> | Yeah, not having to worry about code formatting would be nice |
| 16:26 | <devsnek> | can i use abstract ops from ecma262 in whatwg spec |
| 16:26 | <devsnek> | like IteratorComplete |
| 16:27 | <annevk> | devsnek: yeah, but you gotta declare them ahead of time |
| 16:27 | <devsnek> | also how do i build this |
| 16:28 | <devsnek> | local-watch just errors that index.bs is missing |
| 16:28 | <annevk> | devsnek: which spec? |
| 16:28 | <devsnek> | streams |
| 16:29 | <annevk> | devsnek: make remote |
| 16:29 | <annevk> | devsnek: assuming you have node modules |
| 16:29 | <devsnek> | oh hey a makefile |
| 16:29 | <annevk> | devsnek: if you have bikeshed installed you can also do make local |
| 16:29 | <devsnek> | lol curl: (22) The requested URL returned error: 400 Bad Request |
| 16:30 | <devsnek> | is my spec that bad |
| 16:30 | <annevk> | devsnek: make deploy might give more detailed feedback |
| 16:30 | <devsnek> | nope just 400 |
| 16:31 | <annevk> | devsnek: really? huh, it should also poke at bikeshed and print errors from bikeshed |
| 16:31 | <devsnek> | bikeshed is giving 400 |
| 16:31 | <devsnek> | here's what i did so far https://www.irccloud.com/pastebin/yssMUcXA/broken.diff |
| 16:32 | <Domenic> | devsnek: streams is special |
| 16:32 | <devsnek> | :( |
| 16:32 | <Domenic> | Let me help |
| 16:32 | <Domenic> | It's special in a way that makes things easier |
| 16:32 | <devsnek> | easy would be `make` making the spec >.> |
| 16:32 | <Domenic> | It does! |
| 16:33 | <Domenic> | https://github.com/whatwg/streams/blob/master/Makefile |
| 16:33 | <Domenic> | If you use "local" it'll probably give better error messages |
| 16:33 | <Domenic> | But my guess from source inspection is that Bikeshed doesn't like "method names" that have brackets in them |
| 16:33 | <annevk> | It's weird though that make deploy doesn't give useful error messages |
| 16:33 | <annevk> | Since api.csswg.org does seem to be up |
| 16:33 | <devsnek> | how do i specify Symbol.asyncIterator |
| 16:33 | <Domenic> | devsnek: so I think just remove `method` for now and we can file a Bikeshed bug about this later |
| 16:34 | <Domenic> | Assuming that's the fix |
| 16:34 | <devsnek> | ok |
| 16:34 | <Domenic> | annevk: I think this is a known issue |
| 16:34 | <devsnek> | oh i should also do @@ right |
| 16:34 | <annevk> | devsnek: also, FWIW, if you're stuck you should feel free to upload a PR |
| 16:34 | <devsnek> | ey it built |
| 16:34 | <Domenic> | annevk: oh, no, you fixed this in https://github.com/whatwg/whatwg.org/pull/160, hrm |
| 16:35 | <annevk> | Domenic: what's still "broken" is that we don't fail on it happening, but you should get console messages |
| 16:35 | <Domenic> | \o/ |
| 16:35 | <benjamingr_> | Hmm, is there anything spec-wise for asking an HTTP server to return the response in reverse? |
| 16:35 | <Domenic> | benjamingr_: what does that even mean :) |
| 16:35 | <benjamingr_> | I know it sounds weird lol, let's say I have a file that contains "12345", I'd want it to return "54321" |
| 16:36 | <annevk> | benjamingr_: if you know the length you can ask it byte for byte using ranges... |
| 16:36 | <devsnek> | so reading that issue |
| 16:36 | <devsnek> | the one about async iterators |
| 16:36 | <annevk> | benjamingr_: otherwise, I don't think so |
| 16:36 | <devsnek> | do we still want iterator(options) |
| 16:36 | <benjamingr_> | Yeah - though that's a bit quirky compared to it - basically I wanted to know if there is a way to "race" two HTTP servers (with streaming fetch). I didn't guess there was a way but I thought it was worth asking about. |
| 16:37 | <benjamingr_> | On another similar note - is there a security-related reason that range requests trigger preflight checks? (If so, can I read about it?) |
| 16:38 | <benjamingr_> | devsnek: are you adding `[Symbol.asyncIterator]` to whatwg streams :D ? |
| 16:38 | <annevk> | benjamingr_: https://github.com/whatwg/fetch/pull/560 |
| 16:38 | <annevk> | (and pointers from there) |
| 16:38 | <devsnek> | benjamingr_: thats my intention |
| 16:39 | <benjamingr_> | devsnek: awesome <3 let me know if you want ergonomics - I use whatwg streams as async iterators at work very often. |
| 16:40 | <Domenic> | devsnek: I think it'd be good to add iterator(options), but you could do it as a follow-up. The benefit of doing them together is that they'll probably get implemented together. But if you do them in quick sequence after each other that'll likely also happen. |
| 16:40 | <devsnek> | i don't see much of a reason not to do them together |
| 16:40 | <benjamingr_> | annevk: thanks, that's very helpful. |
| 16:40 | <Domenic> | devsnek: just to save you some work. |
| 16:40 | <devsnek> | am i allowed to use Await and Yield in random productions |
| 16:40 | <Domenic> | devsnek: also IMO it should auto-close and auto-release, I'll say that on the thread. |
| 16:41 | <devsnek> | yeah i agree with that |
| 16:41 | <devsnek> | common case will definitely be that |
| 16:41 | <benjamingr_> | Can I have a link to the said thread? |
| 16:41 | <Domenic> | devsnek: we haven't so far, and I think those are a bit ill-founded. You should be able to get away with just promise stuff. |
| 16:41 | <devsnek> | https://github.com/whatwg/streams/issues/778 |
| 16:41 | <Domenic> | benjamingr_: your thoughts would be much appreciated |
| 16:51 | <annevk> | devsnek: really cool you’re working on this, please consider blogging about it on blog.whatwg.org once done |
| 16:52 | <devsnek> | i'll tweet it about it |
| 16:52 | <devsnek> | Domenic: whats wrong with yield |
| 16:52 | <Domenic> | devsnek: well both Await() and Yield() in specs seem to not cause their containing functions to return the right thing, like they do in JS. But I haven't looked closely. |
| 16:53 | <Domenic> | I think it should be possible to just spec them to return the result of ReadableStreamDefaultReaderRead() or whatever though, and not need any of that? |
| 16:53 | <devsnek> | wdym return the right thing |
| 16:54 | <benjamingr_> | A certain concern with AsyncIterators for streams is how to do BYOB. In my opinion the simplest option is to simply not support it given the alternatives. It's totally doable and I recently explored it but I don't think it's particularly worth it. |
| 16:57 | <devsnek> | maybe we can just do what 262 does and say "the algorithm is implementation defined but it should behave like this block of javascript code" 😆 |
| 17:04 | <annevk> | It does that? |
| 17:07 | <devsnek> | annevk: https://tc39.github.io/ecma262/#sec-enumerate-object-properties |
| 17:08 | <annevk> | That’s a lil different, but okay |
| 17:09 | <devsnek> | no implementation of 262 follows that though so its kinda a moot point |
| 17:15 | <devsnek> | Domenic: so instead of doing await/yield should i do like a ReadableStreamDefaultControllerAsyncIteratorPrototype design? |
| 17:54 | <zcorpan> | Domenic: thanks :) |
| 18:19 | <Domenic> | devsnek: right, that's what I was thinking, a new class |
| 18:20 | <Domenic> | devsnek: (sorry to disappear, had a block of meetings) |
| 18:20 | <Domenic> | "right thing" = promise or generator. At least for Await(), it's pretty magic in the spec, and you can use it inside just normal sync functions and it'll suspend your execution context, which is tricky. |
| 18:21 | <devsnek> | isn't the only difference between functions in the spec the grammar that is allowed |
| 18:35 | <Domenic> | I mean depending on how you deifne "only", I suppose so |
| 19:17 | <Domenic> | Ugh, embed is non-interoperable. But will anyone actually care about fixing it? |
| 21:27 | <Domenic> | Hmm it's a bit sad that if you use shadow DOM fragment navigation breaks. Expected I guess since IDs are not unique any more. Still, I wonder if there's anything we can do... |
| 21:33 | <Domenic> | Ah nevermind, as long as you reproject content into the light DOM it's OK. https://plum-earth.glitch.me/ |
| 23:34 | <Domenic> | annevk: mkwst: have you seen https://github.com/WebAssembly/content-security-policy/blob/master/proposals/CSP.md#proposed-origin-bound-permission ? This proposal seems a little strange to me, but I'm not sure why. I guess I'm confused as to whether things like CSP and SRI are supposed to protect fetches, or executing, or what. |
| 23:34 | <Domenic> | Basically, we have models already for how CSP and SRI affect HTML elements like <script>, and how they affect APIs that execute scripts from URLs like importScripts() or import(), and how they affect APIs that execute scripts from strings like eval() and setTimeout() |
| 23:35 | <Domenic> | But WebAssembly.instantiateStreaming/compileStreaming accept neither URLs nor strings; they accept Responses, which are sort of in between. |
| 23:35 | <Domenic> | Not sure what the right way to apply the model is, but the proposal seems to be trying to treat them more like URL-accepting APIs I guess, by maintaining the relevant data with the response? |