| 05:33 | <gsnedders> | Things I dislike about writing specs in English: no type-checker |
| 07:54 | <annevk> | gsnedders: maybe one day? I feel like we're getting closer |
| 08:23 | <gsnedders> | annevk: I kinda want to implement a high-level version of a bunch of stuff in Dafny |
| 08:23 | <gsnedders> | annevk: for the sake of checking types |
| 08:30 | <xfq> | rewrite the specs in Coq? |
| 08:30 | <xfq> | ;) |
| 08:31 | <Domenic> | This is like a weekly meme now... |
| 08:31 | <MikeSmith> | xfq: be careful, he will take you seriously |
| 08:31 | <Domenic> | The language rotates though |
| 08:32 | <gsnedders> | MikeSmith: what, me and formal methods? never. :P |
| 08:47 | <JakeA> | TypeShed – a tool that turns TypeScript into prose. |
| 08:48 | <JakeA> | import inParallel from "/in parallel"; |
| 08:48 | <JakeA> | etc etc |
| 08:49 | <JakeA> | if someone could build and ship that before lunch that'd be great |
| 08:52 | <TimothyGu> | tobie: thanks for fixing up the rfc keywords :) |
| 08:53 | <Mek> | even better if it could also automatically create tests from it :P |
| 08:57 | <JakeA> | I see a lot of specs not linking terms like "in parallel", "while", "resolve" etc. Should the aim be to link all of these, or is it considered overkill? |
| 09:04 | <TimothyGu> | mkwst: according to a brief google search xuebang.com.cn is basically ratemyprofessors but for Chinese universities |
| 09:04 | <TimothyGu> | well, supposed to be |
| 09:05 | <mkwst> | TimothyGu: Based on my experience with HTTP Archive, I assume everything is porn. |
| 09:05 | <mkwst> | Especially if it contains "bang" in the title, `.cn` TLD or not. :) |
| 09:05 | <TimothyGu> | lol that's honestly a good assumption |
| 09:13 | <annevk> | JakeA: not sure about "while" and "resolve" really needs https://github.com/w3ctag/promises-guide/issues/27 fixed first |
| 09:13 | <annevk> | JakeA: "in parallel" should really be linked |
| 09:16 | <JakeA> | ta! |
| 09:29 | <Ms2ger> | (The internet is really great... For porn) |
| 09:36 | <MikeSmith> | ? |
| 09:36 | <MikeSmith> | that’s kind of .. out of the blue |
| 09:40 | <gsnedders> | eh, I think referencing Hixie's favourite (former favourite?) musical is on-topic in here :P |
| 09:43 | <Domenic> | I'd rather we not :-/ |
| 09:46 | Ms2ger | blames mkwst |
| 09:46 | <mkwst> | MikeSmith: https://github.com/whatwg/html/pull/3011#issuecomment-331391908 <-- |
| 09:48 | MikeSmith | looks |
| 09:48 | <MikeSmith> | aha |
| 09:50 | <MikeSmith> | btw great twitter photo there mkwst |
| 09:50 | <mkwst> | I thought it'd only be funny to me, but people seem amused. :) |
| 09:50 | <MikeSmith> | made me laugh :) |
| 09:51 | <MikeSmith> | anyway I have to tell you I am very sad that I went to all the trouble of attending BlinkOn just so that I could hang out with you, but then you didn’t show up |
| 09:51 | <mkwst> | !!! |
| 09:51 | <MikeSmith> | hehe |
| 09:51 | <MikeSmith> | I made the best of it in spite of the disappointment |
| 09:52 | <mkwst> | Sorry. It's the second week of school: my wife is a teacher, and my oldest daughter just started first grade. My life is way too chaotic right now to jaunt off to Tokyo for a week. :/ |
| 09:52 | <mkwst> | I'll be at TPAC, though! |
| 09:52 | <MikeSmith> | yeah was just trolling |
| 09:52 | <mkwst> | In lovely and exciting Burlingame! |
| 09:52 | <MikeSmith> | will look forward to seeing you there |
| 09:52 | <MikeSmith> | and look forward to exploring the dark side of Burlingame |
| 09:53 | <MikeSmith> | the seedy side I should say |
| 09:53 | <MikeSmith> | people claim there is no seedy side to Burlingame |
| 09:53 | <mkwst> | All I know is that I drive through Burlingame on my way to the airport. And never felt any need to stop. |
| 09:54 | <MikeSmith> | yeah that seems to be the common experience |
| 09:54 | <gsnedders> | yeah, I feel unconvinced there's anything of value there |
| 09:54 | <MikeSmith> | well the places that everybody habitually overlooks are the places where you get by with doing some pretty crazy stuff without attracting attention |
| 09:55 | <gsnedders> | So… Tokyo? |
| 09:55 | <MikeSmith> | yeah |
| 09:56 | <MikeSmith> | there are many overlooked parts of Tokyo that are orders of magnitude more interesting than the well known parts |
| 09:56 | <MikeSmith> | anyway |
| 13:32 | <annevk> | https://twitter.com/wikipediachain/status/911213522218078209 |
| 13:50 | <annevk> | JakeA: did you know about https://dxr.mozilla.org/mozilla-central/source/dom/webidl/FetchObserver.webidl? |
| 13:50 | <annevk> | JakeA: should we create a tracking issue for that? |
| 13:50 | <annevk> | Also https://dxr.mozilla.org/mozilla-central/source/dom/webidl/Request.webidl#59 |
| 13:51 | <annevk> | And https://developer.mozilla.org/en-US/docs/Web/API/FetchObserver |
| 13:51 | <annevk> | I've been missing out |
| 14:18 | <JakeA> | whuuuuuut |
| 14:18 | <JakeA> | annevk: haha no I was not aware |
| 14:18 | <JakeA> | I guess I should be careful what I say in public |
| 14:19 | <gsnedders> | JakeA: why are you not aware of everything? |
| 14:21 | <annevk> | JakeA: what did you say in public? |
| 14:21 | <JakeA> | I know right. Gotta up my game. |
| 14:21 | <JakeA> | annevk: I mean, I roughly sketched FetchObserver, and now it's in Firefox & MDN |
| 14:22 | <JakeA> | (I say "I", really we're all to blame here) |
| 14:24 | <annevk> | ooh |
| 14:24 | <annevk> | Yeah Andrea told me he implemented from https://github.com/whatwg/fetch/issues/447#issuecomment-281731850 |
| 14:24 | <annevk> | Pretty eager |
| 14:38 | <wanderview> | JakeA: its in MDN? its disabled behind a flag because we are not shipping it yet |
| 14:39 | <wanderview> | annevk: JakeA: FetchObserver is disabled by default in firefox AFAIK |
| 14:39 | <wanderview> | hmm... or is it |
| 14:39 | <JakeA> | we only have a half-baked idea right now, and no tests or spec, so it probably shouldn't ship :D |
| 14:40 | <wanderview> | yes, its disabled |
| 14:40 | <wanderview> | annevk: this was when we were trying to push forward on cancelation a bit earlier in the year |
| 14:40 | <JakeA> | cool to see it was implementable though! |
| 14:42 | <wanderview> | I guess MDN says its disabled by default |
| 14:42 | <wanderview> | probably just made some extra work for the dev-doc folks |
| 16:07 | <annevk> | wanderview: baku was asking when it was going to be standardized so he could flip the pref |
| 16:19 | <jyasskin> | annevk: I'm finally working on pulling permissions.request() into an incubation, in https://jyasskin.github.io/permissions-request/. Sorry I didn't get to that way sooner. |
| 16:20 | <annevk> | jyasskin: I don't really care about that distinction personally |
| 16:20 | <jyasskin> | annevk: 'k. I don't have a particularly strong opinion on making it general vs specific. |
| 16:20 | <annevk> | jyasskin: I mostly care about the spectrum of wide support - single vendor support - no support |
| 16:21 | <annevk> | jyasskin: one thing I've wondered with the generic variant is whether it has side effects |
| 16:22 | <annevk> | jyasskin: does getting the persistent storage permission also make your storage persistent |
| 16:22 | <annevk> | for instance |
| 16:22 | <jyasskin> | annevk: Ah, my rule is that something with no- or single-vendor support should be an incubation, and we should pull it into the standards process when it has wider support. |
| 16:22 | <annevk> | or does it just flip the permission bit and you still have to flip the persistent bit yourself using persist() |
| 16:23 | <annevk> | anyway, I guess at this point I can say there's some interest in the more limited variant of request() for a couple one-off legacy APIs that don't have a permission framework around them |
| 16:23 | <annevk> | but I haven't verified with mt |
| 16:23 | <jyasskin> | annevk: Is there anything more detailed about persistent storage than the single bit? If not, I'd lean toward having-permission makes everything persistent. |
| 16:24 | <annevk> | jyasskin: at some point there might be |
| 16:24 | <annevk> | jyasskin: once we have multiple boxes |
| 16:24 | <annevk> | jyasskin: so yeah, I think I wouldn't like a generic API either |
| 16:25 | <annevk> | I vaguely recall this being a concern back in the day too, but I'm not sure we ever discussed it in detail |
| 16:25 | <jyasskin> | What would make a site want some of its boxes to be persistent but others not? |
| 16:26 | <annevk> | jyasskin: make vital persistent, but leave large assets to be collected as needed to avoid being blamed for taking up all the storage when the user runs out |
| 16:26 | <jyasskin> | Thinking about it more, I think I lean toward saying that if the API isn't generic, it should be spelled "requestFoo(...)" instead of "request({name: 'foo', ...})" |
| 16:27 | <jyasskin> | But maybe I've missed an advantage of the {name:'foo', ...} option. |
| 16:34 | <annevk> | jyasskin: I never really understood why permissions were made that complicated |
| 16:34 | <annevk> | jyasskin: implementations still mostly use strings |
| 16:35 | <annevk> | jyasskin: and dialogs to users should hardly ever have more complexity than something resembling a string either |
| 16:35 | <jyasskin> | annevk: Why they have internal structure? Some things, like cameras, have internal structure. It's dumb that browsers don't let the user pick *which* camera to grant access to. |
| 16:36 | <jyasskin> | I'm not convinced that {name:'midi', sysex:true} was a good idea: that could have been "midi-sysex". |
| 16:36 | <jyasskin> | But it predates my involvement. |
| 16:37 | <annevk> | jyasskin: I think that's true, but wouldn't the permission still be camera access? |
| 16:38 | <annevk> | jyasskin: or do we want apps to ask for each camera individually? I don't think iOS does that and it'd seem rather annoying if that's how things worked |
| 16:39 | <jyasskin> | If you look at the specific camera 'request' function, it's got loads of arguments: https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia#Parameters. I think we want the app to describe the cameras that'll work for them, and then users to select which cameras to grant access to. |
| 16:39 | <jyasskin> | It's similar to how file access works. iOS also doesn't make the app get permission to access each file individually, but that's insecure. |
| 16:40 | <annevk> | Yeah, I guess what I'm saying is that at the permission level I still see that as a single bit |
| 16:40 | <annevk> | "This site can play with the camera infrastructure" |
| 16:41 | <annevk> | But it's a good reason not put it in a generic request() API |
| 16:41 | <jyasskin> | (I'm wrong about iOS file access: they have only sandboxed files. Android does it the insecure way.) |
| 16:42 | <jyasskin> | I think "can play with the camera infrastructure" isn't the kind of permission we should be asking users about, and the permissions API (and infrastructure) should reflect the kinds of questions we actually ask. |
| 16:43 | <jyasskin> | I agree that nothing here argues for or against a generic API. I've been pushing slightlyoff to give me code that a generic API allows, which a specific one wouldn't. |
| 16:44 | <annevk> | jyasskin: I guess my main question at this point is that issue I just raised |
| 16:44 | <annevk> | jyasskin: is that something you/Chrome are interested in or should we pursue something more specific somehow |
| 16:45 | <annevk> | I wonder if anyone is volunteering to maintain legacy orientation/motion events |
| 16:45 | <annevk> | I guess I could take a look at some point, but I'm worried there's all kinds of yak shaving to be done there |
| 16:46 | <jyasskin> | Not speaking for Chrome here, but I'd vote for requestSensors() and requestClipboard(...). instead of request('sensors'), etc. I'm still discussing the clipboard aspect with Raymes and Gary. |
| 16:47 | <annevk> | kk |
| 16:47 | <jyasskin> | annevk: I've started to put together https://docs.google.com/spreadsheets/d/1xWK4uf5O3v7xTo85U3X0gGVNfJLD8_W8Zt93BO37we4/edit?ts=59b895ce#gid=0 to comprehensively describe how we guard platform capabilities, which isn't just with permissions. It's not complete, but you might enjoy it. |
| 16:49 | <annevk> | That does look like fun |
| 19:26 | <jyasskin> | Could someone (MikeSmith?) install https://github.com/apps/pr-preview on the https://github.com/w3c/permissions repository? |
| 19:27 | <jyasskin> | Oh, nm. It's not listed in the repository, but https://github.com/tobie/pr-preview says it's already enabled. |
| 19:29 | <tobie> | jyasskin: add a config file using: https://tobie.github.io/pr-preview/config.html |
| 19:29 | <tobie> | jyasskin: and you'll be good to go |
| 19:30 | <jyasskin> | Turns out we already have that file. D'oh. |
| 19:37 | <tobie> | jyasskin: and it's not working? |
| 20:02 | <jyasskin> | tobie: Some older PRs have previews, but https://github.com/w3c/permissions/pull/159 doesn't yet. I thought it might just be being slow, but maybe it's broken? |
| 20:47 | <tobie> | jyasskin: I should find a way to do error reporting, but I'm not sure how. |
| 20:47 | <tobie> | jyasskin: in general, if it takes longer than 30-60 seconds, there's a problem. |
| 20:50 | <mathiasbynens> | aaah, so that’s what it means https://github.com/tc39/ecma262/pull/1010#issuecomment-331554667 |
| 20:54 | <tobie> | jyasskin: I'm not seeing this show up in the logs |
| 20:55 | <jyasskin> | tobie: Whee. |
| 20:55 | <jyasskin> | I can push an update to see if that sends the right ping. |
| 20:56 | <tobie> | jyasskin: just editing text of the issue is enough to restart a build |
| 20:56 | <tobie> | *the |
| 20:56 | <tobie> | jyasskin: add a couple of line breaks |
| 20:56 | <jyasskin> | Edited. |
| 21:01 | <tobie> | jyasskin: ok, something's broken somewhere |
| 21:02 | <tobie> | jyasskin: GH's been flakey today, so is it not sending webhooks? |
| 21:02 | <jyasskin> | tobie: Thanks for checking. |
| 21:04 | <tobie> | jyasskin: I just restarted the server. Can you poke the PR another time? |
| 21:06 | <jyasskin> | tobie: Poked. |
| 21:06 | <tobie> | jyasskin: webhooks aren't working. |
| 21:08 | <jyasskin> | 😢 |
| 21:13 | <tobie> | jyasskin: weird, seems like an issue with the whole W3C org. |
| 21:19 | <tobie> | jyasskin: pinged W3C sysreq |
| 21:21 | <tobie> | jyasskin: working off the assumption pr-preview was removed from the W3C repo by someone, as it's still working for WHATWG, WebIDL, WICG, etc. |
| 21:21 | <tobie> | s/repo/org/ |
| 21:46 | <tobie> | jyasskin: can you give it another try. My logs say someone added the whole org back a couple of minutes ago. |
| 21:46 | <jyasskin> | tobie: I've added a newline. |
| 21:51 | <tobie> | jyasskin: never mind, I can't read a log to save my life. |
| 21:51 | <jyasskin> | :) |
| 21:52 | <tobie> | jyasskin: this was the log of someone removing it, not adding it, and it was earlier today, not minutes ago. |
| 21:52 | <jyasskin> | tobie: Recall that this discussion started when I missed that my repository already contained a .pr-preview file. |
| 21:53 | <tobie> | jyasskin: heh. It's midnight here, on Friday night, and I has some excellent wine earlier, so there's also that. |
| 21:54 | <tobie> | MikeSmith: the logs show your handle mucking with stuff in this area today. Was this removal accidental? |
| 22:00 | <tobie> | jyasskin: OK, so the logs are confusing cause they're async and there's been quite some toggling of that setup button happening today. So the outputs are all intertwined. |
| 22:01 | <tobie> | jyasskin: currently, the app is not longer installed for the W3C org. MikeSmith needs to fix that. |
| 22:02 | <jyasskin> | I like how my first request was correct, but for the wrong reason. |
| 22:09 | <tobie> | jyasskin: that's a pretty cool twist, I agree. |
| 22:11 | <tobie> | Darn, where is botie |
| 23:57 | <MikeSmith> | tobie: where? |
| 23:57 | <MikeSmith> | ah the preview/diff thing |
| 23:58 | <MikeSmith> | yeah I tried to set that up for a specific repo, but from what you said it appears I disabled it for the entire rest of the org? |
| 23:58 | <MikeSmith> | if so I wonder how do I fix it |
| 23:59 | <MikeSmith> | OK I just went back in and in the *Repository access* setting for it, I changed it (back?) to *All repositories* |