| 07:54 | <tobie> | annevk: sounds like you're around: any idea what |value| in step 3 of https://heycam.github.io/webidl/#invoke-a-callback-function corresponds to? |
| 07:56 | <annevk> | tobie: maybe should be callable? |
| 07:57 | <annevk> | tobie: also X there seems wrong? |
| 07:57 | <annevk> | tobie: seems X should be F |
| 07:58 | <tobie> | I'm sort of hesitant to fix this as part of https://github.com/heycam/webidl/pull/198 |
| 07:58 | <tobie> | Thoughts? |
| 07:59 | <tobie> | annevk: ^ |
| 08:00 | <tobie> | I've done a bunch of small straightforward fixes already, but this one seems a lot more involved. |
| 08:07 | <annevk> | tobie: yeah, best as separate PR |
| 08:07 | <annevk> | tobie: don't wanna mix editorial refactoring and normative fixes |
| 08:08 | <annevk> | tobie: even though that is often tempting 😊 |
| 08:08 | <tobie> | annevk: agreed. It's a thin line in some instances, though. |
| 08:08 | <tobie> | annevk: are https://github.com/heycam/webidl/pull/198/commits/8d188f5b648be8976a36d5586a1468988fdead97 |
| 08:08 | <tobie> | and https://github.com/heycam/webidl/pull/198/commits/ad0c8fd0a1a15cb68d9ee4b5fff7fea66ef52734 fine? |
| 08:09 | <tobie> | annevk: or should I back out of them? |
| 08:10 | <annevk> | tobie: alternative is to fix and enumerate in commit message |
| 08:10 | <annevk> | tobie: so that it's very clear what you intended to change |
| 08:11 | <annevk> | tobie: that will help those doing archeology later |
| 08:13 | <tobie> | annevk: squashing will make those small changes suoer hard to find. |
| 08:13 | <tobie> | annevk: I'm torned, now. |
| 08:13 | <tobie> | *super |
| 08:17 | <annevk> | tobie: up to you |
| 08:17 | <annevk> | tobie: lots of refactoring will follow due to ES6 |
| 08:18 | <annevk> | tobie: so might not be worth it too worry about it too much |
| 08:18 | <tobie> | ok |
| 08:21 | <tobie> | annevk: ta |
| 12:25 | <tobie> | In Bikeshed, is there a way to add ignored vars at the algorithm level? |
| 12:26 | <tobie> | Ideally this should not be necessary once we have a way to specify inputs |
| 12:26 | <tobie> | but in the meantime, it would be quite helpful |
| 12:26 | <tobie> | ^ TabAtkins |
| 12:39 | smaug____ | wonders why we have SecureContext in the way it is spec'ed now. Limited to some features but not others. Like, SharedWorkers are handled but very similar BroadcastChannel isn't. Causes false feeling of some safety. |
| 13:06 | <smaug____> | annevk: about two-way fetch and using it for similar to WebSocket. One thing I was thinking is Blob handling. implementations may store the received blob data in temporary files and just pass blob to JS |
| 13:06 | <smaug____> | (that is certainly happening with XHR, because it is used to download huge files which can't be kept in memory all the time) |
| 13:06 | <smaug____> | annevk: supporting that with fetch could be rather tricky |
| 15:47 | <JakeA> | annevk: TabAtkins: I had a bit of a brain-dump about navigation transitions https://github.com/jakearchibald/navigation-transitions |
| 15:53 | <annevk> | JakeA: the fact that navigate itself is somewhat non-interoperable still and poorly understood makes me a little nervous |
| 15:54 | <JakeA> | annevk: Yeah, that's a blocker for transitions |