| 04:45 | <Domenic> | dbaron: https://github.com/mozilla/standards-positions/blob/master/CONTRIBUTING.md#which-specifications seems a little exclusionary :) |
| 04:51 | <annevk> | Domenic: created https://github.com/mozilla/standards-positions/pull/71 |
| 04:51 | <Domenic> | \o/ |
| 04:52 | <annevk> | Pretty sure it's an oversight since we list them elsewhere |
| 04:52 | <annevk> | I hope at some point we'll also include Khronos, Unicode, CA/B, et al |
| 04:52 | <Domenic> | Yeah fair point |
| 04:53 | <Domenic> | Although not sure how many specs the CA/B produces |
| 04:54 | <annevk> | Well, they have a set of guidelines CAs need to adhere to that gets change proposals |
| 04:54 | <annevk> | So they produce at least one "Living Standard" of sorts that I know of |
| 04:55 | <Domenic> | Ah yeah, that fits |
| 04:59 | <Domenic> | annevk: if you're working on DOM bugs today https://github.com/whatwg/dom/issues/371 still really bugs me |
| 05:00 | <annevk> | Domenic: I'd like all the shadow stuff to land first |
| 05:01 | <annevk> | Domenic: also, it's starting to get to me a bit that I'm always cleaning up other folks their trash |
| 05:02 | <Domenic> | :-/ |
| 05:02 | <Domenic> | For shadow DOM that's an issue with how the incubation proceeded I think |
| 05:03 | <Domenic> | Not sure what happened with the service worker thing, seems like it needed more review going in? |
| 05:04 | <annevk> | Yeah, it didn't have enough architectural scrutiny and it took a long time for the lifetime to become somewhat defined |
| 05:05 | <Domenic> | jungkees is doing a lot of the cleanup there, which is great :) |
| 05:05 | <Domenic> | Coupled with WPT upstreaming |
| 05:06 | <annevk> | Yeah, that certainly helps |
| 06:01 | <annevk> | Maybe I can tackle that a bit as it does not touch dispatch |
| 06:23 | <dbaron> | Domenic: merged |
| 06:42 | <kochi> | oops, I'm not used to using GitHub review tool for making comments... |
| 07:25 | <annevk> | TabAtkins: https://github.com/whatwg/dom/issues/185 |
| 08:24 | <annevk> | Domenic: JakeA: to what extent do we still want https://github.com/whatwg/dom/issues/438? |
| 08:25 | <annevk> | Domenic: JakeA: maybe we should file a dedicated issue on serialize/transfer for AbortController and close that one? |
| 08:27 | <Domenic> | Hmm I can't remember why I wanted that :/ |
| 08:40 | <annevk> | That seems like a good reason to close it π |
| 08:50 | <JakeA> | annevk: Domenic: It's interesting, but transferring promises/streams would be higher on my list |
| 08:50 | <Domenic> | Yeah it seems like transferring streams is coming up soon |
| 09:05 | <JakeA> | Domenic: what's the solution for deciding which objects should be transferred, and which should be cloned? |
| 09:05 | <Domenic> | That's the open question |
| 09:05 | <Domenic> | Although at least for readable byte streams we can just easily decide they're all transferred |
| 09:05 | <JakeA> | yeah |
| 09:06 | <JakeA> | controller.enqueue(whatever, transferables) is the best I can think of |
| 09:06 | <Domenic> | For tasklets surma / iank___ contemplated just always transferring all the transferrable things |
| 09:08 | <JakeA> | Sure. Might be weird that it's different to postMessage though. Or stream.pipeThrough(new TransferAll()) |
| 09:08 | <JakeA> | Which could be explained using controller.enqueue(whatever, transferrables) |
| 09:09 | <Domenic> | Yeah c.e(w, t) seems like probably the right primitive? But maybe it should be easier? |
| 09:09 | <Domenic> | I was thinking new ReadableStream({ autoTransfer: true, ... }) maybe |
| 09:10 | <Domenic> | The pipeThrough idea works but feels a bit strange at the moment, hmm |
| 09:10 | <Domenic> | I guess it depends on who we want to be in control |
| 09:11 | <JakeA> | const stream = new ReadableStream({ autoTransfer: true, β¦ }).pipeThrough(new TransformStream()); // what happens if I transfer stream? Has the transform stream unmarked the objects as transferrable? |
| 09:12 | <JakeA> | hmm |
| 09:14 | <Domenic> | Hmm yeah |
| 09:14 | <Domenic> | There are several levels of transferrability here, I guess autoTransfer is not the interesting one |
| 09:15 | <Domenic> | Hmm |
| 09:15 | <Domenic> | Maybe x.postMessage(stream, [ReadableStream.transferChunks])??? |
| 09:16 | <JakeA> | Kinda magic |
| 09:16 | <Domenic> | Orrr even just x.postMessage(stream, []) vs. x.postMessage(stream, [stream]) |
| 09:16 | <Domenic> | I guess the question is, what does the first one do. |
| 09:16 | <Domenic> | Does it tee stream or does it lock it forever and clone the chunks over |
| 09:17 | <Domenic> | s/tee/clone I guess, which we still haven't really done |
| 09:17 | <JakeA> | I figured it'd tee, or throw |
| 09:17 | <JakeA> | yeah I guess cloning is the right thing |
| 09:18 | <JakeA> | But I think the cloning/transferring of the stream is separate to the chunks |
| 09:19 | <Domenic> | I was kinda hoping it wasn't, then we could just use that distinction |
| 09:19 | <JakeA> | At least a transform stream lets you do it on a chunk by chunk basis, but having to make sure it's the very last transform in the sequence might be a gotcha |
| 09:20 | <Domenic> | I'm no longer sure how that would work, except by some kind of magical marking of chunks as transferrable |
| 09:20 | <Domenic> | Because the transfer-or-not decision needs to be made inside the postMessage code |
| 09:20 | <JakeA> | Yeah I guess the stream would have a weakmap of chunks to transferrables |
| 09:21 | <JakeA> | but yeah, I see your point |
| 09:21 | <Domenic> | Auto-transferring seems nice... |
| 09:21 | <Domenic> | We could also add an options bag to all the postMessage APIs... |
| 09:22 | <JakeA> | obj[Symbol.transferrables] π |
| 09:26 | <Domenic> | Let the games begin https://twitter.com/domenic/status/973490376731328513 |
| 09:31 | <nox> | annevk: Around? |
| 09:34 | <annevk> | nox: yeah |
| 09:35 | <nox> | annevk: https://github.com/immersive-web/webxr/issues/25#issuecomment-372602299 |
| 09:35 | <nox> | annevk: If the answer is kill, I'm removing the test from a Servo PR and it should land in WPT soon afterwards. |
| 09:35 | <nox> | annevk: It's just mentioned in WebVR's idlharness tests. |
| 09:36 | <annevk> | nox: sorry, don't know about webxr |
| 09:36 | <nox> | Fair enough. |
| 09:36 | <annevk> | nox: it does seem that if allowvr is implemented that needs upstreaming to HTML / Feature Policy |
| 09:37 | <nox> | annevk: 'allow="vr"' is a thing, |
| 09:37 | <nox> | so probably just something that we forgot to remove. |
| 09:37 | <annevk> | nox: that's feature policy |
| 09:37 | <annevk> | nox: allow= is here to stay |
| 09:37 | <nox> | Yeah that I know. |
| 09:38 | <annevk> | Domenic: hmm, how do you count? |
| 09:38 | <annevk> | Domenic: are Worker and MessageChannel separate? |
| 09:38 | <Domenic> | annevk: IDL method declarations |
| 09:40 | <nox> | Can I kill an arrow function in a test? |
| 09:40 | <nox> | Servo still doesn't support them. |
| 09:40 | <annevk> | nox: I'd rather you not |
| 09:40 | <nox> | Well I guess we won't run those tests then. What could go wrong? |
| 09:41 | <annevk> | nox: I land stuff with them all the time and they're actually more readable |
| 09:41 | <nox> | I don't see how "more readable" enters the picture here. |
| 09:41 | <nox> | Now I need to maintain a separate fork of tests. |
| 09:41 | <annevk> | nox: in that I likely have to read that test again in the future |
| 09:42 | <annevk> | nox: there's a root problem here and the arrow functions are not it |
| 09:42 | <nox> | annevk: Ok. |
| 09:43 | <annevk> | Domenic: I wonder if that's really the upper bound, given AudioWorklet |
| 09:43 | <Domenic> | annevk: I checked, AudioWorklet uses MessagePort |
| 09:44 | <Domenic> | Servo should just give up and add Babel at this point |
| 09:44 | <annevk> | Domenic: hurray |
| 09:44 | <nox> | No, we should get our SM bump, |
| 09:44 | <nox> | but SM's build system is⦠Well it exists. |
| 09:45 | <nox> | May have brainfarted anyway, I think the arrow function itself is borken. |
| 09:45 | <nox> | Is `r => r.text()` supposed to work? |
| 09:45 | <nox> | β β invalid arrow-function arguments (parentheses around the arrow-function may help) |
| 09:46 | <Domenic> | yeah it should... |
| 09:46 | <annevk> | Need to be more ambitious, re-introduce IronMonkey but now with the meaning of being a JS impl in Rust |
| 09:46 | <nox> | So we are on a SM version that choke on some arrow functions or something, wonderful. |
| 09:47 | <annevk> | That seems really weird |
| 09:48 | <nox> | annevk: Oh no. The expression on which it chokes is in `async`, |
| 09:48 | <nox> | which is probably what we are actually missing. |
| 09:53 | <annevk> | That makes more sense |
| 10:02 | <nox> | annevk: Is -manual a special test name suffix? |
| 10:04 | <annevk> | nox: yeah, it means it cannot be automated |
| 10:04 | <annevk> | nox: well, that it's not automated |
| 10:04 | <nox> | :) |
| 10:19 | <hsivonen> | w3c-test.org timing out for everyone or just for me? |
| 10:20 | <annevk> | hsivonen: wfm |
| 10:20 | <hsivonen> | annevk: thanks |
| 10:20 | <hsivonen> | it worked for me too a short while ago |
| 10:23 | <hsivonen> | ooh. now it came back |
| 10:56 | <annevk> | I just realized that if you use event handler attributes you leak an event listener until the element is GC'd |
| 11:57 | <Domenic> | yes that seems accurate |
| 11:57 | <Domenic> | Well it's the same as event listeners though? |
| 11:57 | <Domenic> | In both cases you can remove manually, but if you don't, they leak |
| 12:16 | <annevk> | Domenic: you cannot remove an event handler |
| 12:16 | <Domenic> | annevk: el.onfoo = null? |
| 12:16 | <annevk> | Domenic: does not remove the listener |
| 12:17 | <Domenic> | sure, but now the listener does nothing, so I can't imagine engines keep around much if any memory for it |
| 12:17 | <annevk> | Sure, but still |
| 12:17 | <Domenic> | Not sure I'd call that a leak |
| 12:22 | <AutomatedTester> | what is supposed to happen when there is a shadow DOM and element(s)FromPoint is called on that area? |
| 12:23 | <AutomatedTester> | do we always need to check the shadowRoot exists and use that? |
| 12:23 | <AutomatedTester> | what happens if its a closed shadowRoot? |
| 12:24 | <annevk> | AutomatedTester: https://github.com/w3c/csswg-drafts/issues/556 |
| 12:26 | <AutomatedTester> | annevk: thanks! |
| 23:00 | <jyasskin> | annevk/hsivonen: Regarding the worries about CBOR in https://github.com/mozilla/standards-positions/issues/29#issuecomment-334376573, have you gone through WebAuthn to make sure its use of CBOR and CDDL is fine with you? I'm working on improving the CBORbis spec precision (https://github.com/cbor-wg/CBORbis/compare/master...jyasskin:editorial-improvements), but WebAuthn also depends on CDDL which is even less precise. |